You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Volker Hejny <V....@fz-juelich.de> on 2005/03/15 10:49:56 UTC
svn merge on branches containing moved files/directories
Dear all,
I'm currently facing a problem, which - after reading all documentation -
I was sure subversion can handle.
Summary: A branch was created to do a major redesign of the directory
structure. Normal maintanance was done on trunk in parallel. When trying
to merge the branch back into trunk, all changes on files which had been
moved in the branch were lost. The same happens to files, which were
added to trunk in directories which are renamed in the branch. I'm using
subversion 1.1.3, the original problem occurs using the svn+ssh protocoll,
but the basic example below I did with a local repository.
The example:
- I created a local subversion repository file:///repo and import as
trunk the following files:
dir1/file1
dir1/file2
- I created a branch using
svn copy file:///repo/trunk file:///repo/branches/branch1
-m 'creating branch1'
This created revision 3
- I checked out branch1 and did the following changes:
svn move dir1 dir2
svn commit
This created revision 4
- I checked out trunk and did the changes:
editing dir1/file1
touch dir1/file3
svn add dir1/file3
svn commit
This created revision 5
- Now I tried to merge branch1 to trunk:
cd trunk
svn update (well, to be sure)
svn merge -r 3:HEAD file:///repo/branches/branch1
A dir2
A dir2/file1
A dir2/file2
D dir1/file1
D dir1/file2
D dir1/file3
D dir1
Result: dir1 is empty (file3 removed) and dir2/file1 does not
contain the changes from dir1/file1 in trunk (revision 5)
What I expected was to get a conflict for file3 (new file in directory
which is to be deleted) and a proper handling of changes in file1.
Originally I switched from cvs just because of subversion's ability to
version directories and to allow renames. Well, hopefully I'm doing
something wrong in the example above ...
Best regards,
Volker
--
Dr. Volker Hejny Tel: 02461/616853 **
Institut f. Kernphysik Fax: 02461/613930 **
---------------------------------------------------------------- ** ** ---
Forschungszentrum Juelich GmbH, D-52425 Juelich **
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Volker Hejny <V....@fz-juelich.de>.
On Tue, Mar 15, 2005 at 01:41:05PM -0600, Ben Collins-Sussman wrote:
>
> On Mar 15, 2005, at 12:10 PM, Volker Hejny wrote:
> > The request to delete these
> >files - to my opinion - must give a conflict. The user than knows
> >that he has to take care of that.
>
> Well, running 'svn status' will show your file as '?'. That's a pretty
> clear indication that it's something to take notice of.
As described in the initial example: Both files in question, the
changed one and the added one, are deleted by svn, i.e. no longer
there. There are not just 'unversioned'. There are no files any more
which can be marked as '?' and taken care of later.
What you describe is the behaviour on locally modified files when
issue an 'svn update'. That's fine.
The problem is in 'svn merge':
trunk -------1----2-------4--------
| ^
| | merge
branch --------3-----
At (1) the branch the created, at (2) a file is modified in trunk,
at (3) the corresponding file in branch is deleted. During merge
at (4) (which would look like 'svn merge 1:3 branch' the file is delete
in trunk, too, although is has been changed between revision 1 and 3
in trunk.
Well, one can argue, that since the file has been deleted in branch,
any changes are no longer important. However, in reality the file
has not just been deleted but copied and deleted. The changes in
trunk would be of interest for the copy.
At the moment, the only solution is to manually track down any
of these copy/delete-change problems, i.e. actually do the
code-management again manually and search what files are copies
of which.
The one thing, which subversion could do during merge, is to warn the
user that a file is going to be delete which was changed meanwhile.
At the moment, the file is going to be deleted independent of whether
is still unchanged or not. There is no way to find out from the
output. However, subversion has all the information to give this
support.
Of course, a real 'move' would solve this problem, too, but I think
including such a warning would be a very helpful intermediate
solution.
Best regards,
Volker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 15, 2005, at 12:10 PM, Volker Hejny wrote:
>
> Well, does subversion really delete an edited file without giving
> a conflict?
No, it just makes the file 'unversioned'. It refuses to delete
irreplaceable data.
If the file (or directory) has no local changes at all, then yes, 'svn
up' will actually delete the thing.
> The request to delete these
> files - to my opinion - must give a conflict. The user than knows
> that he has to take care of that.
Well, running 'svn status' will show your file as '?'. That's a pretty
clear indication that it's something to take notice of.
The sort of 'conflict' marker you're talking about, (when status shows
'C'), is specifically for textual conflicts, not for tree-based
conflicts.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Volker Hejny <V....@fz-juelich.de>.
On Tue, Mar 15, 2005 at 08:43:18AM -0600, Ben Collins-Sussman wrote:
>
> Subversion doesn't have moves; it has copies and deletes. And as a
> result, it can lead to a lot of confusion.
Ok, concerning the copy I see the difference. Actually I was aware of
that, but didn't see the consequence that clear.
> For example, if a user does 'svn mv A B', it's really exactly the same
> as running 'svn cp A B; svn rm A'. Let's say this user then commits
> the change.
> Meanwhile, a different user has made edits to A. He now runs 'svn
> update', and receives not a 'move', but a 'copy and delete' from the
> server. His edited A gets deleted (well, not really -- because it's
> edited, it merely becomes unversioned), and he receives this new file
> called B. But when he looks inside B, he sees it's just a copy of a
> *older* version of A.
Well, does subversion really delete an edited file without giving
a conflict?
However, in my case it's merge instead of update. And the changes in
trunk were committed, so subversion IS aware of the fact that these
files were changed/added since branching. The request to delete these
files - to my opinion - must give a conflict. The user than knows
that he has to take care of that.
In my example the changes are deleted without further notice. In a
large project there is no way to keep track of that.
> So no, you're not crazy. Your situation with 'svn merge' is just
> another variant on this. When you 'svn merge' your
> directory-reorganization branch to a different place, you're not
> getting 'moves' of what happens to be there already. You're getting a
> bunch of deletes and adds of older things.
The adds of older things are ok, but the current behaviour when
deleting changed files I would consider as a bug.
Best regards,
Volker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Scott Palmer <sc...@2connected.org>.
On Mar 18, 2005, at 3:12 PM, Stefan Haller wrote:
> Huh? I don't see how this is any different from textual conflicts
> within a single file.
Contextual changes within a single file that had local modifications is
slightly different because those local modification have not been
committed yet. If the destination file of the merge didn't have local
modifications, but has modification that were committed in the
destination branch and there is a conflict with those committed changes
then you are right - this appears to be the same thing.
I was thinking along the lines of it not mattering that some bug was
fixed in a module that isn't needed at all anymore. The assumption
being that scope of the file delete encompasses all possible changes
that would have happened in that file, i.e. they don't matter to the
rest of the code if there is a greater change that removes the entire
file, then along with that delete must come changes to the rest of the
files that make whatever went on inside the deleted file meaningless.
But that is a flawed assumption.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Stefan Haller <ha...@ableton.com>.
Scott Palmer <sc...@2connected.org> wrote:
> I can see why subversion would go ahead with scheduling the delete
> because no information will be permanently lost in this case. The
> problem is that I can imagine some cases where you would want the
> delete to silently go through because the changes in the destination
> branch are no longer relevant if that entire file is no longer needed,
> and yet I can see the other side, where the changes should not be wiped
> out by deleting the file because the changes are not part of what the
> original branch was trying to undo by the delete.
Huh? I don't see how this is any different from textual conflicts
within a single file. If one developer deletes a section of code in a
file, and another developer commits a change to that same section of
code (or vice versa), of course you want to have a conflict. You
absolutely don't want Subversion to silently drop some changes because
the context of those changes no longer exists.
--
Stefan Haller
Ableton
http://www.ableton.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Scott Palmer <sc...@2connected.org>.
On Mar 18, 2005, at 10:21 AM, Volker Hejny wrote:
> Note: That was not I was talking about! Locally-modified files are
> handled
> carefully and in the same way as 'update' does. The point is, that the
> file is not 'locally modified', but the modification was already
> comitted
> to trunk. In that case, the file is deleted silently.
Ah, I understand now. The 'last modified' revision of the file is
greater than the one that was deleted in the source branch, so the
merge is actually removing changes made in the destination branch that
the source branch was unaware of. Yes, I see how that can be something
that deserves a warning or conflict state of some sort.
I can see why subversion would go ahead with scheduling the delete
because no information will be permanently lost in this case. The
problem is that I can imagine some cases where you would want the
delete to silently go through because the changes in the destination
branch are no longer relevant if that entire file is no longer needed,
and yet I can see the other side, where the changes should not be wiped
out by deleting the file because the changes are not part of what the
original branch was trying to undo by the delete.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Volker Hejny <V....@fz-juelich.de>.
On Fri, Mar 18, 2005 at 09:31:51AM -0600, Steve Greenland wrote:
> On Fri, Mar 18, 2005 at 04:21:15PM +0100, Volker Hejny wrote:
> > Note: That was not I was talking about! Locally-modified files are handled
> > carefully and in the same way as 'update' does. The point is, that the
> > file is not 'locally modified', but the modification was already comitted
> > to trunk. In that case, the file is deleted silently.
>
> But if you run 'svn status' before you commit the merge, you will
> see the 'D', right?
This is correct, of course. However, it does not help, because there
are a lot of other files with 'D', which had not been changed since
the branch was created. The problem is to identify those files, which
were changed/added since the branch was created _and_ are going to be
deleted now.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Steve Greenland <st...@lsli.com>.
On Fri, Mar 18, 2005 at 04:21:15PM +0100, Volker Hejny wrote:
> Note: That was not I was talking about! Locally-modified files are handled
> carefully and in the same way as 'update' does. The point is, that the
> file is not 'locally modified', but the modification was already comitted
> to trunk. In that case, the file is deleted silently.
But if you run 'svn status' before you commit the merge, you will
see the 'D', right?
Steve
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
-- (Stolen from the net)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Volker Hejny <V....@fz-juelich.de>.
Hi Ben and Scott,
On Thu, Mar 17, 2005 at 09:05:28PM -0600, Ben Collins-Sussman wrote:
>
> On Mar 17, 2005, at 7:17 AM, Scott Palmer wrote:
> >
> >>As described in the initial example: Both files in question, the
> >>changed one and the added one, are deleted by svn, i.e. no longer
> >>there. There are not just 'unversioned'. There are no files any more
> >>which can be marked as '?' and taken care of later.
> >
> >he was mistaken?
Not at all. The files actually were deleted. That's also what 'svn delete'
is doing: scheduling a file for deletion in the repository, but already
delete it in the working copy. (And this behaviour of svn delete is
fully ok and reasonable.)
> I have no idea. Perhaps Volker was confused by what he saw. The 'svn
> merge' command will "skip" over a locally-modified file, rather than
> delete it. Try it yourself.
Note: That was not I was talking about! Locally-modified files are handled
carefully and in the same way as 'update' does. The point is, that the
file is not 'locally modified', but the modification was already comitted
to trunk. In that case, the file is deleted silently.
Volker
--
Dr. Volker Hejny Tel: 02461/616853 **
Institut f. Kernphysik Fax: 02461/613930 **
---------------------------------------------------------------- ** ** ---
Forschungszentrum Juelich GmbH, D-52425 Juelich **
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 17, 2005, at 7:17 AM, Scott Palmer wrote:
>
>> As described in the initial example: Both files in question, the
>> changed one and the added one, are deleted by svn, i.e. no longer
>> there. There are not just 'unversioned'. There are no files any more
>> which can be marked as '?' and taken care of later.
>
> he was mistaken?
>
I have no idea. Perhaps Volker was confused by what he saw. The 'svn
merge' command will "skip" over a locally-modified file, rather than
delete it. Try it yourself.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Scott Palmer <sc...@2connected.org>.
On Mar 16, 2005, at 10:23 AM, Ben Collins-Sussman wrote:
> On Mar 16, 2005, at 8:37 AM, Scott Palmer wrote:
>
>> I had always assumed that under the hood merge (or at least half of
>> it) was implemented with the same code that does update.
>
> Nope, completely different code.
>
> There's a huge difference: update actually changes the *foundation*
> of your working copy...
Ah, of course.
>> How is it that a merge is able to delete a modified file where an
>> update does not?
>
> Merge doesn't delete the file, it merely *schedules* a deletion, as if
> it had typed 'svn rm file'. The scheduling is revertable, or, if the
> user likes it, can commit, and then the deletion is "real".
So when Volker wrote:
> As described in the initial example: Both files in question, the
> changed one and the added one, are deleted by svn, i.e. no longer
> there. There are not just 'unversioned'. There are no files any more
> which can be marked as '?' and taken care of later.
he was mistaken?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 16, 2005, at 8:37 AM, Scott Palmer wrote:
>
> On Mar 16, 2005, at 9:14 AM, Ben Collins-Sussman wrote:
>
>>
>> When merging in the other direction, the merge command silently
>> deletes the newer version of the file.
>>
>
> I had always assumed that under the hood merge (or at least half of
> it) was implemented with the same code that does update.
Nope, completely different code.
There's a huge difference: update actually changes the *foundation* of
your working copy: the text-bases, the working-revision, etc. A merge
does nothing but make local edits to your working copy: everything
that a user could do by hand -- edit working files, run 'svn add' or
'svn rm'.
> How is it that a merge is able to delete a modified file where an
> update does not?
>
Merge doesn't delete the file, it merely *schedules* a deletion, as if
it had typed 'svn rm file'. The scheduling is revertable, or, if the
user likes it, can commit, and then the deletion is "real".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Scott Palmer <sc...@2connected.org>.
On Mar 16, 2005, at 9:14 AM, Ben Collins-Sussman wrote:
>
> When merging in the other direction, the merge command silently
> deletes the newer version of the file.
>
I had always assumed that under the hood merge (or at least half of it)
was implemented with the same code that does update. How is it that a
merge is able to delete a modified file where an update does not?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 16, 2005, at 7:51 AM, Greg Thomas wrote:
>
> However, if the developer moved A->A1 and copied A1->A2 and A2->A3,
> then removed the extra stuff, there's at least the possibility that a
> merge could resolve this.
>
I think Stefan has a good point though. Forget all about splitting of
files, moves, and copies.
The simple fact is: "tree conflicts" still happen. One one branch, a
file may be deleted, and on another branch the file might be changed.
When merging the latter branch to the former branch, we get a 'skipped'
message: the merge command is unable to apply a change to a file
that's just not there. When merging in the other direction, the merge
command silently deletes the newer version of the file.
I wonder if we can teach the merge command to notice this situation,
and throw a warning, flag the file, do something. It's worth a
discussion on dev@ if somebody wants to bring it up there.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Moving a directory [Thanks]
Posted by Mike Dewhirst <mi...@dewhirst.com.au>.
Dominic Anello wrote:
> On 2005-04-28 17:51:03 +0100, Hakan Koseoglu wrote:
>
>>Hi Mike,
>>
>>
>>>I should have said I am using TortoiseSVN and didn't see a Move option.
>>>There was a relocate but it there was a scary warning.
>>
>>That's true! TortoiseSVN I have installed on my Windows machine
>>doesn't have a move command. On the other I believe hand they have
>>their own users mailing group. I just assumed you meant svn command
>>line.
>
> ----8<----
>
> To move in TSVN, right-drag the file to the new location, a context menu
> will pop up when you release the mouse button with an option to "Move
> items in subversion here". You can also copy this way using TSVN.
GREAT - thanks Dominic
>
> -Dominic
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Moving a directory
Posted by Dominic Anello <da...@danky.com>.
On 2005-04-28 17:51:03 +0100, Hakan Koseoglu wrote:
> Hi Mike,
>
> > I should have said I am using TortoiseSVN and didn't see a Move option.
> > There was a relocate but it there was a scary warning.
> That's true! TortoiseSVN I have installed on my Windows machine
> doesn't have a move command. On the other I believe hand they have
> their own users mailing group. I just assumed you meant svn command
> line.
----8<----
To move in TSVN, right-drag the file to the new location, a context menu
will pop up when you release the mouse button with an option to "Move
items in subversion here". You can also copy this way using TSVN.
-Dominic
--
If you've got a vision, then I don't want to see
If you've got a notion -- don't waste it on me
Re: Moving a directory
Posted by Hakan Koseoglu <ha...@gmail.com>.
Hi Mike,
> I should have said I am using TortoiseSVN and didn't see a Move option.
> There was a relocate but it there was a scary warning.
That's true! TortoiseSVN I have installed on my Windows machine
doesn't have a move command. On the other I believe hand they have
their own users mailing group. I just assumed you meant svn command
line.
TortoiseSVN's relocate is a synonym of svn's command "switch
--relocate" and it is not a move command. It is used when your
repository is re-arranged and you want to switch to the new URL so
you did the right thing by not using relocate.
Simply switch means use an other branch, switch --relocate means the
location of the server has changed, update my configuration so that it
poinst to the right place. I bet the SVN book is actually much
clearer than I am so here's the link: http://svnbook.red-bean.com/
--
Hakan (m1fcj)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Moving a directory
Posted by Mike Dewhirst <mi...@dewhirst.com.au>.
Hakan Koseoglu wrote:
> On 4/28/05, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
>
>>How do I move a directory within a project?
>
> svn help move
Thanks Hakan
I should have said I am using TortoiseSVN and didn't see a Move option.
There was a relocate but it there was a scary warning.
As it happens, I have done the deed manually. It was quite tricky
because this particular project is a static website I am reworking for a
client (it isn't my specialty) using Dreamweaver 4.
If you move or rename directories or files *in* the Dreamweaver window,
it carefully rewrites any necessary changes throughout the site. I rely
on that to refactor mercilessly.
I just deleted the paragraph I wrote describing what I did because it
got so convoluted even I didn't understand what I'd written. I must have
got it right by sheer good luck rather than skill and logic.
Thanks again
Mike
> Svn move command essentially does what you just described, it copies
> the file and deletes the original but you don't have to worry about
> the typing the commands twice.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Moving a directory
Posted by Mike Dewhirst <mi...@dewhirst.com.au>.
How do I move a directory within a project?
I figure I can copy it to where I want it, mark the original one for
deletion and add the new copy in the new location.
Is there a smarter way?
Thanks
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 16, 2005, at 8:25 AM, Stefan Haller wrote:
>
> My problem is that the "true moves" feature that Ben was talking about
> is still no complete solution to the problem, and it is probably not
> going to be implemented any time soon. I need a solution now; we are
> afraid of losing data.
>
Careful with the terminology; no data is lost. It's all still in the
repository's history and can be recovered. The goal here is for users
not to accidentally delete changes that they've not yet personally
examined.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Stefan Haller <ha...@ableton.com>.
Greg Thomas <th...@omc.bt.co.uk> wrote:
> On Wed, 16 Mar 2005 14:33:35 +0100, haller@ableton.com (Stefan Haller)
> wrote:
>
> >Now consider the case where a developer works on file A in his branch;
> >he decides that A has become too large, so he splits it in three new
> >files A1, A2, and A3, then he deletes A. (No move involved.)
>
> The developer has deliberately created new files with no history and
> no link to the original - there is no way any system could resolve
> this.
Of course, I don't expect the system to resolve this for me; I just
expect it to tell me about it (loudly) so that I get a chance to resolve
it manually.
My problem is that the "true moves" feature that Ben was talking about
is still no complete solution to the problem, and it is probably not
going to be implemented any time soon. I need a solution now; we are
afraid of losing data.
--
Stefan Haller
Ableton
http://www.ableton.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Wed, 16 Mar 2005 14:33:35 +0100, haller@ableton.com (Stefan Haller)
wrote:
>Now consider the case where a developer works on file A in his branch;
>he decides that A has become too large, so he splits it in three new
>files A1, A2, and A3, then he deletes A. (No move involved.)
The developer has deliberately created new files with no history and
no link to the original - there is no way any system could resolve
this.
However, if the developer moved A->A1 and copied A1->A2 and A2->A3,
then removed the extra stuff, there's at least the possibility that a
merge could resolve this.
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Stefan Haller <ha...@ableton.com>.
Ben Collins-Sussman <su...@collab.net> wrote:
> So no, you're not crazy. Your situation with 'svn merge' is just
> another variant on this. When you 'svn merge' your
> directory-reorganization branch to a different place, you're not
> getting 'moves' of what happens to be there already. You're getting a
> bunch of deletes and adds of older things.
>
> This is why, after we finish locking, that "true moves" are the next
> big item we want to fix.
Ben, I think that "true moves" are only a partial solution to this
problem.
We are working with a development model where virtually no work is done
on the trunk; all development takes place on branches. If a task is
done, the branch is merged to the trunk and deleted.
Now consider the case where a developer works on file A in his branch;
he decides that A has become too large, so he splits it in three new
files A1, A2, and A3, then he deletes A. (No move involved.)
Meanwhile, another developer makes changes to A in *his* branch. Later,
when both branches are merged to the trunk, the second developer's
changes to file A will be lost, silently.
I think this is a huge problem that needs addressing.
We have the feeling that the problem can be solved by introducing the
concept of "directory conflicts". (I'm not talking about textual
conflict markers here, but about the "C" that you see in svn status.)
If a merge brings in a change for a file that has been deleted in the
target, the containing directory should be marked as conflicting
(instead of, or in addition to, the "skipped missing target" message
that you now get during the merge); conversely, if a merge would cause a
file to be deleted that has a higher revision number in the target than
the revision where the file was deleted in the source, there should be a
conflict too. This is the case where you now lose data completely
silently, which is evil.
Until Subversion supports something like this, we are now having two
problems:
1) How can we find out whether we might have lost changes in the past?
We are thinking about writing a script that parses svn -v log output,
somehow checking that deleted files are not modified in another
branch at a higher revision or something. I'm not yet clear about
the exact algorithm needed here.
2) How can we make sure that this problem doesn't occur in the future?
Again, we are thinking about an automated solution, something like
remembering all deleted files in a database, and having a pre-commit
hook check that no modifications are committed to a file that was
deleted in another branch.
This is all very preliminary yet, I was just wondering if anybody has
already thought about these issues and have any ideas about the matter.
--
Stefan Haller
Ableton
http://www.ableton.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn merge on branches containing moved files/directories
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 15, 2005, at 4:49 AM, Volker Hejny wrote:
> Dear all,
>
> I'm currently facing a problem, which - after reading all
> documentation -
> I was sure subversion can handle.
Subversion doesn't have moves; it has copies and deletes. And as a
result, it can lead to a lot of confusion.
For example, if a user does 'svn mv A B', it's really exactly the same
as running 'svn cp A B; svn rm A'. Let's say this user then commits
the change.
Meanwhile, a different user has made edits to A. He now runs 'svn
update', and receives not a 'move', but a 'copy and delete' from the
server. His edited A gets deleted (well, not really -- because it's
edited, it merely becomes unversioned), and he receives this new file
called B. But when he looks inside B, he sees it's just a copy of a
*older* version of A.
So no, you're not crazy. Your situation with 'svn merge' is just
another variant on this. When you 'svn merge' your
directory-reorganization branch to a different place, you're not
getting 'moves' of what happens to be there already. You're getting a
bunch of deletes and adds of older things.
This is why, after we finish locking, that "true moves" are the next
big item we want to fix.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org