pmarek@users.sourceforge.net writes:
> > 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)
In fairness, there might be remaining bugs like this that crop up in
the presence of missing dirs. But those are bugs resulting from
coders not paying attention to all the valid states in which a working
copy could find itself, not indications of a design flaw in the
program.
> > > + 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.
Of course, the minute you separate your working files from their
text-bases by a real filesystem boundary, you pay a performance
penalty when moving files across that boundary, such as when preparing
a working file for commit (from the admin 'tmp' area) or when making a
new text-base "live" as part of an update. Hm, but I might be
exaggerating this a bit since we probably are doing
"copy-and-translate" instead of "move" anyway.
> > > + 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.
Yes, theoretically, those are the differences -- today as well as in
your plan. But that doesn't mean we'd choose to merge those two code
chunks. The use of lack thereof of the admin area was obviously
significant enough of a difference for Ben to choose to write a new,
easy-to-read editor, rather than wedge more conditionals into the
existing update editor.
> > - 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 ... :-]
But wait a second. Now my users are blissfully unaware that they are
looking at versioned data, so they go moving things around willy nilly
using the regular filesystem commands -- without using Subversion, and
without "changing the paths in [the] config area". Now my working
copy is completely out of whack! Where's the goodness in that?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 31 08:40:14 2003