> > > > + 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.
Or you could just move the prop-files in another filesystem - via symlinks or
mounts in the "new" administrative area.
> 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.
Well, that's a valid cause.
> > > - 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?
That's the same as now. Now they move directories around, and svn doesn't
automatically move the files in the repository.
But wait, there's a perl-script for doing imports, isn'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 09:30:18 2003