> > - 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.
OK, I missed that. You're right. I just saw some discussion about
svn:externals and thought that something similar could be done this way - but
you're right.
> > 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'.
At least in my "old" version of svn (I believe 0.24 or some svn snapshot about
there), if a complete directory is missing, a "svn diff" says
svn: Working copy not locked
svn: directory not locked (<missing directory>)
Maybe that's fixed by now. (Ok, I didn't bother with the issues)
> > + 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:
Well, I don't know about your trees, but using svn for versioning gives you an
extra of +900% inodes - see eg
subversion/tests/clients/cmdline/working_copies/basic_tests-1:
# find . | wc
180
# find . | grep -v "\.svn" | wc
18
That's nice IMHO to put on another filesystem; especially the prop-base and
prop-text directories could do with many inodes but small filesystem blocks.
> + get to name your administrative directory anything you want to,
> including (but not limited to) .pmarek-is-my-hero
Thank you :-)
> > + maybe a consolidation between export and checkout/update
>
> That's sufficiently vague. What about our current .svn layout hinders
> such a consolidation today?
Well; AFAIK both could amount to *exactly* the same but export doesn't use the
administrative area, does it?
If I look into subversion/libsvn_client/ there is a lot of difference between
export and checkout and update. But I grant you, I'm not familiar enough with
svn; there may be some differences I didn't notice.
> > 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'.
You move your wc and change your paths in your config area. Done.
I know, currently it's easier - just move the directory - but see the next
point:
> - can't even tell that a given directory is a versioned one without
> attempting an operation like 'svn st' on it.
But that's the beauty of this *additional* functionality!! You just take an
existing tree, put your administrative files elsewhere, and version the full
tree without your users noticing!!
I would even think about using that as a backup mechanism - with full
versioning ... :-]
> > 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.
Well, that depends on the relative weights you give the arguments, doesn't
it??
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 31 07:53:09 2003