You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Barry Scott <ba...@barrys-emacs.org> on 2003/12/17 20:22:47 UTC
Adding a new file to a patch work flow problem
I came across this problem when I was submitting a patch against
rapidsvn. IS this a candidate to fix for 1.0 as this is very
inconvenient for patch submitters? Do you want a issue logged?
Workflow:
1. create patch that adds a file
2. submit patch to maintainer
3. maintainer merges the patch to the repo
4. update wc fails
> prompt addbug:$S
addbug: if exist repo rmdir /s /q repo
addbug: if exist wc1 rmdir /s /q wc1
addbug: if exist wc2 rmdir /s /q wc2
addbug: svnadmin create repo
addbug: svn mkdir file:///l:/subversion/bugs/repo/fred -m blah1
Committed revision 1.
addbug: rem work on patch for fred
addbug: svn co file:///l:/subversion/bugs/repo/fred wc1
Checked out revision 1.
addbug: echo file1 1>wc1/file1.txt
addbug: svn add wc1/file1.txt
A wc1\file1.txt
addbug: rem merge patch for fred
addbug: svn co file:///l:/subversion/bugs/repo/fred wc2
Checked out revision 1.
addbug: echo file1 1>wc2/file1.txt
addbug: svn add wc2/file1.txt
A wc2\file1.txt
addbug: svn ci wc2 -m blah2
Adding wc2\file1.txt
Transmitting file data .
Committed revision 2.
addbug: rem see if patch was done as submitted
addbug: svn update wc1
svn: Obstructed update
svn: Failed to add file 'wc1/file1.txt': object of the same name already exists
addbug: endlocal
Re: Adding a new file to a patch work flow problem
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2003-12-18 at 16:47, Barry Scott wrote:
> My expectation was that svn up would see that the file is added in the
> wc and update wants to add so they match semantically. Then it would
> just do the merge/conflict stuff as happens to versioned files.
No, I don't think svn will ever do such a thing. Contextual merging
happens between two versions of the *same* file, both under version
control. But in your scenario, svn views the situation as two users
trying to add a certain filename to the repository at the same time.
It's not prudent to assume that the two files are related, just because
they have the same name; instead, this is viewed as a conflict of
*intent*, rather than a conflict of content. In other wods, it's a
"tree" conflict, not a content conflict. ("Hey, you can't add a brand
new file 'foo.c', because there's already one there.")
There are similar scenarios to this as well -- one user deletes a file,
while another one changes it. Whoever commits first, well -- the second
guy is going to get tree conflict when they either commit or update.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Adding a new file to a patch work flow problem
Posted by Mike Mason <mg...@thoughtworks.net>.
Barry Scott wrote:
>
> My expectation was that svn up would see that the file is added in the
> wc and update wants to add so they match semantically. Then it would
> just do the merge/conflict stuff as happens to versioned files.
Whilst I agree it would be great for Subversion to detect this and do
something useful, I don't know of a single other version control system
that will handle this gracefully (answers on a postcard please!).
Perforce would say conflict, CVS would say "move your file, it's in the
way!", StarTeam would report "unknown" (very helpful that one). I admit
I don't know much about fancy things like arch, BitKeeper and svk.
Even if it did handle it, you'd probably want to know that someone else
added the file you wanted to add, with identical contents. Then you
might want to go talk to that person about how you two can communicate
better in future! ;-)
Cheers,
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Adding a new file to a patch work flow problem
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 18-12-2003 17:22, Ben Collins-Sussman wrote:
>Your recipe below isn't a bug. 'svn up' is trying to add a file to the
>working copy. If an unversioned file by the same name is obstructing
>the addition, that's a real obstruction. If a file by the same is
>scheduled for addition, that's an obstruction as well. Subversion
>doesn't have any way of knowing that the schedule-add file is identical
>to the one 'svn up' is trying to add.
>
>I suppose it could compare the two files byte-for-byte, and then do a
>"tree merge" during the update, effectively undoing the schedule-add.
>But that's a whole new class of sophistication. libsvn_wc simply
>doesn't do tree-merges yet. This is just one of many, many examples
>where 'svn up' halts because it doesn't know how to do tree merges.
>Adding these sorts of heuristics is a post-1.0 feature request.
O.k. post 1.0 sigh...
My expectation was that svn up would see that the file is added in the
wc and update wants to add so they match semantically. Then it would
just do the merge/conflict stuff as happens to versioned files.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Adding a new file to a patch work flow problem
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2003-12-17 at 14:22, Barry Scott wrote:
> I came across this problem when I was submitting a patch against
> rapidsvn. IS this a candidate to fix for 1.0 as this is very
> inconvenient for patch submitters? Do you want a issue logged?
>
> Workflow:
>
> 1. create patch that adds a file
> 2. submit patch to maintainer
> 3. maintainer merges the patch to the repo
> 4. update wc fails
Your recipe below isn't a bug. 'svn up' is trying to add a file to the
working copy. If an unversioned file by the same name is obstructing
the addition, that's a real obstruction. If a file by the same is
scheduled for addition, that's an obstruction as well. Subversion
doesn't have any way of knowing that the schedule-add file is identical
to the one 'svn up' is trying to add.
I suppose it could compare the two files byte-for-byte, and then do a
"tree merge" during the update, effectively undoing the schedule-add.
But that's a whole new class of sophistication. libsvn_wc simply
doesn't do tree-merges yet. This is just one of many, many examples
where 'svn up' halts because it doesn't know how to do tree merges.
Adding these sorts of heuristics is a post-1.0 feature request.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org