[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re[2]: Files that were deleted from trunk and re-added later, disappear during merge+commit into branch.

From: <michael_at_tigersoft.co.il>
Date: Tue, 2 Jun 2009 10:05:35 +0200

Hi Ben,

Thanks for your help on this issue.

Here are the clarifications about the problem :

>I'd like to help, but I'm having a hard time following your
>description. Could you be more specific?

[A] We're talking about feature branch. We perform merges from trunk to our feature branch on regular basis.

> So this is after you've just performed a merge, yes?

[A]
1. Merge from trunk to feature branch (let's say we should get revisions 100, 101, 103, 104, 105, 107. In revision 101 we see file <myFile> was added, in 103 – deleted, and in 105 – added again).
2. Change a file not affected by the merge and commit this file
3. Try to commit results of the merge to the branch

>What exactly was the merge command?

[A] TortoiseSVN: Merge a range of revisions => Next => Next => Merge

>And it modified a working copy: of what, the trunk? The branch?

[A] The branch

> Was said working copy up-to-date before you performed the merge?

[A] It was up-to-date – just one person works on this branch from the same working copy

>A file deletion, perhaps?

[A] Yes

> So files that got deleted from trunk, also got deleted from trunk? Que?

[A] After the update and commit we have <myFile> deleted. I believe after merge back (from fetaure branch) we'll have <myFile> deleted in trunk as well.

>I can't tell because I'm having trouble with:
>What did you do?
>What actually happened?
>What did you expect to happen?

[A] We expect to see <myFile> in the branch working copy in the end of the merge.
Actually, what we see is:
1. Commit of merged (from trunk) changes is failed ("Working copy is not updated") though branch's working copy is up-to-date.
2. When we perform update => update log that should be empty shows that <myFile> was deleted. This deletion doesn't appear in the branch's log.
3. Bottom line: branch's working copy is compromised => branch will be compromised after commit.

Just to reiterate the problem here is the problem desciption again:
Short description:
Files that were deleted from trunk and re-added later, disappear during merge+commit into branch.
 
Flow:
1. I'm working in my branch (it's a "feature branch"); according to SVN recommendations I merge from trunk to branch periodically
2. During the last "merge+commit" I saw following behavior: on 1-st attempt to commit I've received "Commit failed" message.
Reason: "Working copy is not updated"
3. OK, I've updated my working copy; as a result number of files were deleted (it looks like Tortoise brakes SVN "commit" atomicity on the previous step)
4. After next "commit" all "merged" changes were committed => now we have these files deleted on server side as well
Final result: when we'll merge our feature branch back we'll have compromised trunk
 
Additional info:
Between "merge" and "commit" I've committed a little "private" (not related to merge) change into the branch.
When on stage 3 I've updated my branch, I was "blessed" with deletions "added" to my "private" change revision number though it can't be discovered by the log.
 
I hope this helps to clarify the problem.

-- 
Best regards,
Michael Liberman 
 
 IT Consultant
 TigerSoft LTD.
 Office: +972 (0)8 942 7052
 Fax:    +972 (0)8 942 0447
 Mobile: +972 (0)54 441 3995
 E-mail: Michael_at_Tigersoft.co.il
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2358661
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-02 09:07:38 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.