On Wed, Apr 22, 2009 at 02:27:40AM +0200, Greg Stein wrote:
> Hey all,
>
> I believe that I might be seeing a bug in the local-add-with-history
> and update-with-incoming-add. (NOTE: this is a regular old wc-1
> problem)
>
> First off, I have no idea what "use case" this is. The numbers seem to
> be all messed up. update_editor.c:1561 says 3.5, but
> notes/tree-conflicts/ has something else entirely for "use case 3". So
> color me confused.
I have no idea what 3.5 is supposed to be, either.
Isn't there a comment that explains what is meant?
But anyway, keep in mind that virtually everything in notes/tree-conflicts
is outdated. We have a much better and more fine-grained understanding of
tree conflicts at this point than the notes reflect.
Sadly, the notes don't reflect what we know, it's all in the heads
of a couple of people and scattered across the mailing lists :(
> Anyways... the particular setup for demonstration this occurs in
> update_tests 34. On line 2675 of update_tests.py, an update is run
> which will try to bring in a new omicron to replace my
> locally-copied-to-omicron. This is marked as a conflict. All good.
>
> However, within .svn/entries, omicron is still listed as schedule-add.
> I believe this is wrong. I think it should be schedule-replace.
Yes, so that the default behaviour is your local change. "Replace
this incoming omicron from r4 with my one, please" should be the
default behaviour. I agree. The r4 omicron is already versioned,
so less damage is done by accidentally replacing it than when
dropping the locally added omicron.
> After the update, the directory is listed as revision 4, which *has*
> an omicron in it. Thus, my local copy should be replacing that file.
Yes.
> ----
>
> Step 2. Even worse. "svn revert omicron" to revert my (apparent) local
> add. The file omicron's schedule-add is removed, and the file becomes
> unversioned. "svn up" does nothing since the client thinks it has r4
> completely.
>
> The revert *should* revert to the omicron sent down from the server.
> Worst case, it could revert to a "deleted" state, which an "svn up"
> would correct by pulling down a new copy of the file.
Yes. I believe we have an issue with the number of text bases in wc-1
here, and also with how incoming adds are being done. I think Julian
has been struggling with these kinds of questions before.
Update just installs a new text base, the old one is gone.
Or something...
Point being: I don't care about fixing bugs in wc-1 anymore.
Make wc-ng do the right thing. You already have the right behaviour
in your head, so if you can, please make wc-ng do the right thing.
Thanks,
Stefan
Received on 2009-04-22 12:57:13 CEST