On Nov 16, 2006, at 4:37 PM, Andy Peters wrote:
> On Nov 16, 2006, at 4:55 PM, Tim Hill wrote:
>
>> Actually, I think there are *fewer* problems with the
>> "distinct" .svn tree:
>>
>> 3. No problems with folder delete. At present, if you delete a
>> folder (and the .svn hidden folder), svn loses any memory that the
>> folder was there.
>
> I find that feature very useful. When I'm done using a working
> copy, I simply delete it and it's gone (after, of course,
> committing any changes I wish to commit).
>
> But if you got rid of the .svn folder, then you'd need a separate
> command to delete the unneeded working copy; otherwise you've got
> your working copy in a confused state as svn _thinks_ the directory
> exists when it doesn't.
You can still do that -- to the *entire* working copy, of course. I
don't think it's any different for partial working copies. If you
just do a delete on a folder at present, and then an svn update, svn
is still going to try and recover that folder, so it's not *really*
gone any more than in the "single .svn" model. In fact, in the
single .svn model, svn can be smarter about spotting this, since it
still has the .svn metadata; for example, if you really didn't want
that folder around, you could use an svn command to say "don't fetch
this tree", and that could be persisted for that working copy --
rather a useful feature, I would say. In effect, you can create
custom "views" into the repo.
>
>> 4. No "mixed" working copies. Nasty things happen if you use svn
>> checkout to create a disjoint working copy within an existing
>> working copy. The single .svn tree can handle this since the tool
>> can determine the context of the entire tree.
>
> Methinks the mixed working copy issue is a user error. Don't check
> out a working copy into an existing working copy ...
Well, yes: but if we never made mistakes why would we need version
control? :) The issue is that with a single .svn model this error
cannot happen. And who should be doing the book-keeping? Use or the
computer? Isn't managing the dumb stuff what they are for?
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 01:49:59 2006