On Thu, Mar 29, 2001 at 08:16:51AM -0600, Ben Collins-Sussman wrote:
> Then this is a user-interface issue, I suppose: should the 'svn add'
> command contact the repository immediately to determine if there's a
> conflict? I don't think it should. I've always been annoyed that CVS
> does this when you add a directory.
I was thinking of looking at SVN/entries, to see if there was already
an entry there. The commit should have removed the add="true" part, no?
Thus we can see if it is already in the tree or not, at add time,
without talking to the repository.
> Instead, svn treats adds and deletes like any other local mods -- it's
> just a local mod on a dir, instead of a file. At commit time, you'll
> get tree-structure conflicts along with your textual ones.
> Or, look at it from the other direction: suppose 'svn add' immediately
> checked the repos for tree conflicts. Then for consistency, 'svn cp'
> and 'svn mv' and 'svn rm' would all have to do the same. Isn't this
> going a bit too far?
Good point! I guess I was thinking of a little bit of preliminary
checks, before commit time, but maybe you are right. I would
investigate a little more, but right now svn segfaults everytime I try
> Yeah, better error messages are on our to-do list. :)
Yeah, I know, just thought I would mention it.
> Also: regarding the fact that your working copy was left locked:
> that's a genuine bug! The commit-driver *should* be removing all
> locks if the commit fails in the middle. I'll see if I can reproduce
> that. (although make check works). I'll try to track that down first.
Okay, that would be nice.
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
Received on Sat Oct 21 14:36:26 2006
- application/pgp-signature attachment: stored