Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, Mar 29, 2001 at 07:47:35AM -0600, Ben Collins-Sussman wrote:
> > bugmaster@tigris.org writes:
> >
> > > + echo "File Contents" > file
> > > + svn add file
> > > + svn ci
> > > + svn add file
> > > + svn ci
> > > +
> > > + I get the following output:
> > > + Adding ./file3
> > > +
> > > + svn_error: #21052 conflict at "/file3"
> > > +
> >
> >
> > Um, this isn't a bug.
> >
> > If you add and then commit a file that already exists in the latest
> > tree, that's a commit conflict. Either your wc is out-of-date
> > (i.e. you didn't know the file already existed in the repos), or
> > you're not replacing the file correctly. If you want to replace file
> > with a *totally new* file by the same name, you must
>
> I wasn't trying to replace it, I was just testing strange cases. What I
> meant was that the second svn add (note add, not commit) above should have
> said, "Wait, I already have `file' in the repository, I can't add it again."
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.
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?
> > Same situation here. The worst thing you can say is that our
> > error-reporting isn't descriptive enough. :)
> >
>
> I guess that is sort of what I meant.
Yeah, better error messages are on our to-do list. :)
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.
Received on Sat Oct 21 14:36:26 2006