You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jeff Putsch <pu...@mxim.com> on 2002/09/11 23:57:08 UTC
Possible bug with add and update
Howdy,
I'm using Subversion built from r3146.
If I have a repository and two users (u1, u2) check out the same URL to
their own working copies, then do the following in their respective
working copies:
o Each creates a file called "baz"
o Each "adds" a file called "baz" (now it's marked locally for adding)
o u2 commits baz
o u1 tries to commit baz, it fails as it should
o u1 tries to update baz, it fails until baz is moved out of the way
o u1 moves baz out of the way and updates the working copy. baz
is updated from the repository.
o u1 tries to commit. The commit fails because baz cannot be added
to the repository.
The last item/behavior seems like a bug to me. u1's update of baz from
the repository should have cleared the "add" setting in the local
working copy, but it doesn't.
I've attached a short shell script that will demonstrate the problem
clearly.
If I'm confused about how this is supposed to work, I apologize, but
this sure seems like a bug to me.
Thanks,
Jeff.
--
Jeff Putsch Email: putsch@mxim.com
Maxim Integrated Products Office: (503)547-2037
High Frequency CAD Engineering
Re: Possible bug with add and update
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Vladimir Prus <gh...@cs.msu.su> writes:
> > Well, it shouldn't clear an `add' setting, but it should respect that
> > setting and claim a conflict, thus requiring the user to clear the add
> > setting before the update will succeed.
>
> I've probably missed something. Why do you prefer this behaviour?
> Won't be it better to handle this almost like ordinary conflicts: put
> repository version into working copy under fancy name, without
> changing the original one, and then let the user choose whatever
> version he likes. I guess it's not possible to merge them in the usual
> way, because there's no common base, but moving file out of the way is
> inconvenient. I did not like this in CVS.
I am proposing to handle it like ordinary conflicts, as far as
possible. The current behavior is not to report a conflict at all;
that's the bug.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Possible bug with add and update
Posted by Vladimir Prus <gh...@cs.msu.su>.
Karl Fogel wrote:
> Jeff Putsch <pu...@mxim.com> writes:
>
>> o Each creates a file called "baz"
>>
>> o Each "adds" a file called "baz" (now it's marked locally for adding)
>>
>> o u2 commits baz
>>
>> o u1 tries to commit baz, it fails as it should
>>
>> o u1 tries to update baz, it fails until baz is moved out of the way
>>The last item/behavior seems like a bug to me. u1's update of baz from
>>the repository should have cleared the "add" setting in the local
>>working copy, but it doesn't.
>
>
> Well, it shouldn't clear an `add' setting, but it should respect that
> setting and claim a conflict, thus requiring the user to clear the add
> setting before the update will succeed.
I've probably missed something. Why do you prefer this behaviour? Won't
be it better to handle this almost like ordinary conflicts: put
repository version into working copy under fancy name, without changing
the original one, and then let the user choose whatever version he
likes. I guess it's not possible to merge them in the usual way, because
there's no common base, but moving file out of the way is inconvenient.
I did not like this in CVS.
- Volodya
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Possible bug with add and update
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Jeff Putsch <pu...@mxim.com> writes:
> o Each creates a file called "baz"
>
> o Each "adds" a file called "baz" (now it's marked locally for adding)
>
> o u2 commits baz
>
> o u1 tries to commit baz, it fails as it should
>
> o u1 tries to update baz, it fails until baz is moved out of the way
>
> o u1 moves baz out of the way and updates the working copy. baz
> is updated from the repository.
When you say "moved out of the way", do you mean Unix mv (or the
Windows equivalent)? You don't mean 'svn rm', right?
> o u1 tries to commit. The commit fails because baz cannot be added
> to the repository.
Sounds like a bug. If u1 only renamed the file out of the way, and
didn't affect its added status in Subversion, then u1's update should
have failed because the added entry still exists.
> The last item/behavior seems like a bug to me. u1's update of baz from
> the repository should have cleared the "add" setting in the local
> working copy, but it doesn't.
Well, it shouldn't clear an `add' setting, but it should respect that
setting and claim a conflict, thus requiring the user to clear the add
setting before the update will succeed.
> I've attached a short shell script that will demonstrate the problem
> clearly.
Cool!
Sounds like a bug to me too. Can you file it as an issue?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org