You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Vladimir Prus <gh...@cs.msu.su> on 2002/11/25 12:25:57 UTC

Conflicts between added files.

Hello

Suppose I've added a file in WC. Then I send a patch to
and it's applied in the repository. I update and get
an error, saying that the file already exists.

This is rather common and inconvenient situation. Given
that 3-way merge is not possible, the question is what
behaviour is the best. I believe that WC file should be
modified to show all changes made in repository. I.e.
it should has conflict marker for every change from
repository. This way I can see what exactly was changed.

After experimenting with diff3, I've got the behaviour
which is close to what I want, using

   diff3 -Am my repo my

Example files and merged result is attached. Does this
behaviour look reasonable?

If so, I can try to change update to use this command
when handling file addition.

- Volodya


Re: Conflicts between added files.

Posted by Vladimir Prus <gh...@cs.msu.su>.
Garrett Rooney wrote:
> Ben Collins-Sussman wrote:
> 
>> You claim that this is a common situation.  Is that true?  In a year
>> and a half of using Subversion every day, I've never seen this
>> scenario happen before.  Why does it happen to you so often?
>>
> 
> this is common for people who don't have commit access to the repository 
> in question.
> 
> they are creating a patch which involves adding files, then they submit 
> the patch to the maintainer, he applies it, they update and get a conflict.
> 
> that said, i think ben is correct, and the current behaviour is correct 
> from a safety standpoint.  i'd rather a little annoyance than a lot of 
> potential data loss.

There is NO potential for data loss. This case will be treated as merge with 
conflict, so you'd have your original file and repository file readily
available.


- Volodya


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Conflicts between added files.

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Ben Collins-Sussman wrote:

>You claim that this is a common situation.  Is that true?  In a year
>and a half of using Subversion every day, I've never seen this
>scenario happen before.  Why does it happen to you so often?
>

this is common for people who don't have commit access to the repository 
in question.

they are creating a patch which involves adding files, then they submit 
the patch to the maintainer, he applies it, they update and get a conflict.

that said, i think ben is correct, and the current behaviour is correct 
from a safety standpoint.  i'd rather a little annoyance than a lot of 
potential data loss.

-garrett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Conflicts between added files.

Posted by Ben Collins-Sussman <su...@collab.net>.
Vladimir Prus <gh...@cs.msu.su> writes:

> I do:
> 
>      svn add foo
> 
> and send "foo" to somebody else, who does:
> 
>      svn add foo
>      <some minor edits of foo>
>      svn ci
> 
> Then I do:
> 
>      svn up
> 
> and get the "obstructed update" error message.

Ah, I understand, thanks.

In which case, I disagree with your plan of action.  In this
situation, I do not think the svn client should attempt to merge
changes into your copy of foo, because there's no reason to believe
(and no way to know) that the two files are related.  It would be very
bad to merge a patch from an unrelated file... especially when your
copy of foo isn't really under version control yet.  Your copy of foo
isn't in the repository yet, and there's no text-base of it yet, so
the contextual merge has the potential to destroy your data: there's
no way to simply revert or undo the conflict markers.

You claim that this is a common situation.  Is that true?  In a year
and a half of using Subversion every day, I've never seen this
scenario happen before.  Why does it happen to you so often?



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Conflicts between added files.

Posted by Vladimir Prus <gh...@cs.msu.su>.
Ben Collins-Sussman wrote:
> Vladimir Prus <gh...@cs.msu.su> writes:
> 
> 
>>Suppose I've added a file in WC.
> 
> 
> You mean, there is a file scheduled for addition, but not yet
> committed?  Or do you mean that it's been committed?

Scheduled for addition.

> 
> 
>>Then I send a patch to and it's applied in the repository. I update
>>and get an error, saying that the file already exists.
> 
> 
> I'm sorry, I don't understand your scenario.  Can you give a recipe in
> terms of specific svn commands?
> 

I do:

     svn add foo

and send "foo" to somebody else, who does:

     svn add foo
     <some minor edits of foo>
     svn ci

Then I do:

     svn up

and get the "obstructed update" error message.

- Volodya



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Conflicts between added files.

Posted by Ben Collins-Sussman <su...@collab.net>.
Vladimir Prus <gh...@cs.msu.su> writes:

> Suppose I've added a file in WC.

You mean, there is a file scheduled for addition, but not yet
committed?  Or do you mean that it's been committed?

> Then I send a patch to and it's applied in the repository. I update
> and get an error, saying that the file already exists.

I'm sorry, I don't understand your scenario.  Can you give a recipe in
terms of specific svn commands?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org