pmarek@users.sourceforge.net writes:
> - We define an environment variable (and/or a file/an
> entry in ~/.subversion/) with a list of working copies,
> mapped to other directories. eg
> SVN_WC_BASES=/home/user/project1=/home/user/.wc/proj1:/home/user/project2=/home/user/.wc/proj2
> so the working copy which has it's text files in
> /home/user/project1 would use a tree in /home/user/.wc/proj1
> for storage of .svn-data.
No. No no no. Why an environment variable? Isn't that what we have
a config area for?
> - svn:externals could be done this way too, if the definition would
> be like SVN_WC_BASES=/home/user/project1=/home/user/.wc/proj1:/home/user/project1/sub/sub/external=/home/user/.wc/proj2
The point of svn:externals is that not every user has to set them up
for themselves. One person figures out the right layout, sets a
property, commits, and now everyone else on the team shares the bounty
of his effort.
> Pro:
> + eg a fileserver can easily be versioned, without user irritation because
> of the .svn-directories (samba may hide them; but if a user deletes a
> directory, the .svn therein gets deleted too, and that confuses svn)
Deleting a Subversion directory does not confuse Subversion. That
directory is noted as missing, and can be retrieved again using 'svn
update'.
> + saving of a few inodes (the repeated .svn-direcories vanish as the tree
> is summed in one location)
Really stretching for "pros" here, aren't you? Let me help:
+ get to name your administrative directory anything you want to,
including (but not limited to) .pmarek-is-my-hero
> + maybe a consolidation between export and checkout/update
That's sufficiently vague. What about our current .svn layout hinders
such a consolidation today?
> Con:
> - Work has to be done
> but that should be limited to subversion/libsvn_wc/adm_files.c
> open_adm_file() (*)
> - complexity
> - possibilities of error
> - environment may change from one user to another, and the
> ~/.subversion does too. So maybe we should record the root in the
> .svn/entries-file like the repository-uuid.
- working copies are no longer relocatable unless we implement yet
more subcommands like 'svn pack' and 'svn unpack'.
- can't even tell that a given directory is a versioned one without
attempting an operation like 'svn st' on it.
> And to be honest, I see a lot of advantages. and if all that is needed for
> step 1 is to change open_adm_file() - why not ??? (yes, yes ...
> feeping creaturism and so on)
Really? Your "pros" list was a little lean, IMO.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 30 17:14:41 2003