> I don't know how to say this except bluntly!! Sorry if I step on some toes, but I
> am most unhappy right now. In grumbling around, this issue has bitten more
> people than just me, although I may have the most severe repercussions from
> this issue.
> To be fair, I do not know if it is an SVN issue or a Tortoise issue. For this
> grumble, I'll consider them as the same culprit, called it.
> If you tell me to grumble to SVN, I'll do so!!!
Yep, most all of this is due to the way SVN works and has nothing inherently to do with TortoiseSVN . That said, they are doing quite a bit in 1.8 to deal with stuff like this.
> In my current project, I created myBranch a long time ago. I am working on
> some independent code which doesn't require accessing the other developer's
> code. The other developers have branched and merged several times in the
> meantime. Their current branch is different from the original branch from which
> I created myBranch. Also, their code has been severely reorganized, with many
> folders removed and others added.
The tool can only do so much. If you expect to merge branch changes back to the origin you have to keep the branch up to date. Every day that goes by without merge in from the origin is going to make it more difficult when you do finally move. So, rule number one with feature branches, merge early and merge often.
> I am now ready to merge myBranch back to theirBranch which, as I said, is
> different from theOriginalBranch.
>
> I first wanted to merge theirBranch to myBranch, to resolve any code conflicts
> and make the merge from myBranch to theirBranch easier.
>
> I have not even been able to get the merge from theirBranch to myBranch
> accomplished. I've spent 3 long hard frustrating days attempting to get the
> merge done. It is not happening.
Yep... see above.. this is mostly because you let the origin of your branch and your branch live separately for so long.
>
> The problem is that I am getting a huge number of treeConflicts which, AFAIK,
> are unresolveable.
They certainly are resolvable.. the issue is that it is a manual process and the more conflicts there are the more work it is. Generally you have to manually create missing folders, and duplicate moves, etc in your branch. No, it's not fun.
>
> 1) I spent 3 hours the other day, walking down these tree conflicts and using
> the context menus, came up with a resolution to each conflict. At the end, I had
> a branch that was checked in and apparently up-to-date.
> 2) They made some changes to theirBranch. So I attempted to do another
> merge from theirBranch to myBranch. I got an equally daunting list of these
> treeConflicts.
This doesn't make sense. Once you checked the merge into your branch and trees were basically synced up a new merge shouldn't have brought all those back. Did the merge info from the previous merge get correctly recorded? Many people don't realize that they need to submit from the root folder including changes to the root folder where merge info is maintained by svn.
> 3) I attempted to work my way through them but they never stabilized and I
> never got the second merge accomplished.
> 4) Now I have a broken myBranch and an unmergeable situation from
> theirBranch.
> 5) So I contacted our SVN gurus here and we spent 2-3 hours looking at the
> issues and their response was "We don't know what to do to resolve this." Aw,
> guys, thanks a lot.
> 6) My manager told me about a "trick" that works. Except he is reintegrating
> from the branch back to the trunk. I'm going the other way.
> 7) So, all I have left is to copy the head of myBranch into a newBranch from
> theirBranch. But then I've lost all of my history. Not good.
What history did you lose. All the history of your branch should still be in the repository? Unless you went and dumped the repository and deleted revision I can't see how this is possible. I assume you are saying the rather than merge your changes in you just copied the modified files in?
>
> Anyway, I'm not a happy camper right now!
>
> The issue apparently surrounds all of these folder changes they made in
> theirBranch. It also appears that it "forgot" the common ancestor with all of
> the branching/merging that has occurred in theirBranch.
>
> There has got to be a way for it to be able to do something with these
> TreeConflicts. In reading the documentation, it gives a horrible number of
> scenarios which cause those treeConflicts and what to do in each case, but it's
> MergeDialog doesn't tell you which of those Scenarios it is seeing, nor do the
> dialogs lead you through the appropriate steps necessary to resolve the
> treeConflict nor do the dialogs match anything in the helpFiles.
>
> So I read the help files and try to follow them in the dialogs and get
> nowhere. Nor do our SVN gurus! So I conclude that it is extremely broken on
> doing anything but the simplest merge.
Once again, the longer the paths deviate the harder it will be to merge. I think this is true with any system.
>
> I am most unhappy about this! :{
>
> I argued to our group that we should move to SVN. Now I'm sitting here with
> egg on my face with my peers.
>
> I do not like this.
>
> I come from a ClearCase background. ClearCase 1) versioned the folders along
> with the files inside the folders and 2) allowed the user to actually edit the
> contents of the folders and 3) allowed you to say "I want this file from this
> branch in this folder from that branch." In addition, ClearCase has a 3-way
> merge that you can choose from: Branch1, Branch2 and CommonAncestor. You
> can choose to use any one of the three or to edit the contents to be what you
> want it to be.
>
> This allowed the user to resolve these types of conflicts.
>
> It needs a similar methodology.
>
> This can be accomplished. ClearCase proves that.
>
> Y'all need to do something about this non-sense, so that a user can actually get
> done what the user needs to get done, without grief, pain, frustration and
> irritation.
See the work they are doing in 1.8 with respect to automatic merge and conflict resolution. The svn developers do know about these issues and where things can be automatically resolved they want to do that. They are working on recording moves so that merges can understand that if a file that you branched was moved and has changes that the merge can move this file and apply those changes.
>
> Right now I have all of four of them!!
>
> If I were asked today to recommend a versioning tool, it would NOT be a
> Tortoise/SVN combination.
>
> Sorry to be blunt, but that is the way it is.
Every tool has tradeoffs. Some handle certain scenarios better than others. Also, you have to know how to use a tool. Did you request help on the svn mail list while you were attempting to do your merge to understand what was happening? Are you sure that you always branched/merged from a common root? Are you sure you always committed from the root folder so your merge info would be recorded?
I'm curious if clear case was so brilliant, why did you move away from it? There must have been some problem with it that svn solved which caused you to switch?
BOb
>
> -Ralph Owens
> Ro6690_at_att.com
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3049979
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-02-27 22:44:07 CET