On Tue, Jun 2, 2009 at 10:05, <michael_at_tigersoft.co.il> wrote:
> 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
Ok, this seems odd, not that I expect it to break anything. It just
seems odd to perform the merge, thus creating local edits, then edit
something else by hand, commit that separately and only then commit
the actual merge.
I'd never do that for fear of accidentally including stuff in the
merge that didn't belong there.
>>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
If you got actual changes from the repository on update, then the
working copy can't have been up-to-date relative to the
repository. (Unless, of course you've just discovered a bug in
subversion here.) I've never seen this kind of behavior. Please have
a closer look at this point. Perhaps you can describe a way to
repeat it.
>> 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.
OK, let me try to summarize: You were unable to commit the merge
because you were not up to date with the repository. (This may have
occured due to the interventing commit of the unrelated file.) You
performed an update in order to be able to commit. The update deleted
a file locally.
That means that the file that vanished from your local copy *must*
have been deleted previously on the branch. (Else why would the
deletion arrive as part of an update.) Secondly, an update to the
working copy does not produce a change that will be comitted. (So it's
not like the "commit" is causing the problem, as far as I can tell.)
The problem appears to be that <myFile> was deleted on the branch
between the time you updated your working copy previous to the merge
and the time you tried to commit the merge.
And yes, if such a change is on the branch, it will be included in the
merge when you push your feature branch back into the trunk. The file
deleted on the feature branch will then be deleted on trunk.*
* I'm handwaving past some 'tree conflicts' stuff here because I
don't understand the various constellations well enough.
>>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.
It can't be up-to-date because of the intervening commit. The "file
not affected by the merge" you comitted will be up-to-date relative to
the repository, but the root directory of your branch, for example,
will be at least one revision behind. (To understand why, "Mixed
Revision Working Copies" [1].)
[1]: http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
This means that any directories in the branch which received
svn:mergeinfo will need to be updated before they can be committed.
> 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.
Are you certain? Did you look at the list of changes for the revision
that created the branch? Was the branch perhaps created by copying
from a working copy of trunk and not from a repository URL?
> 3. Bottom line: branch's working copy is compromised => branch
> will be compromised after commit.
Agreed: since this file deletion is on the branch (however it might have
gotten there), it will propogate to trunk when you merge it back.
>
> 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.
This is why you were forced to update before you could complete the
commit of the merge.
> 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.
This deletion must be coming from somewhere, and the merge can't be
the reason since that hasn't been comitted yet.
> I hope this helps to clarify the problem.
I've tried to reason through your account based on my own experiences
with Subversion, but I haven't been able to come up with a good
hypothesis to account for what you've reported. Sorry, I'm a bit short
on brilliant insights today.
One thing I can't do, is reproduce this behavior based on this
description. A concise recipie to reproduce this behavior would help
greatly in identifying this as a bug and getting it fixed. Even
trying to find such a recipe and failing has value, since it would
tend to indicate either a "user error", or perhaps some
hard-to-identify interaction of subversion's features. (??? merge +
mixed rev working copies + branch from working copy = chaos ???)
// Ben
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2358910
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-02 23:20:07 CEST