Re: Merge, branch, reintegrate, problem

Gonzalo Bourdieu <gonzalobourdieu_at_gmail.com> writes:

> At first stage, i was using the branch-first, then integrate to trunk
> strategy. So, i create branches/0.2 and when i finish working on
> that, i merge everything to the trunk, and after that, i branch it to
> the 0.3 (from the trunk). After realizing that this was not the best
> strategy for my workflow, i (at version 0.7) change to another
> strategy. Work in the trunk, and when a version was ready, at that
> moment i branch to (for example) 0.8 and leave the trunk to continue
> working on the new version (0.9). The bug fixes where made over the
> branch, and then they were merge with the trunk.

I think it's very important to be clear on "feature branch" vs "stable
branch", where "feature branch" I define as one wants to merge all
changes on the parent to the feature branch frequently, and then will do
--reintegrate and delete the feature branch. Stable branches are ones
where you do not necessarily want to always merge from the parent and
then reintegrate. Your develop on trunk, make stable branch for
release, and if you make bugfixes on trunk or stable merge them to the
other (cherrypicking the fix, not taking all) makes sense to me.

> My situation now is that i have:
> /branches/0.9 with the latest stable code
> /trunk/ with the latest code (with all the changes made it in 0.9 merged)
>
> For all this merging i always use the simple merge. But now, i'd create a
> new feature branch from the trunk. So at this time, i'll have:
> /branches/0.9
> /branches/ft_amazon_s3
> /trunk
>
> An i passing day by day all the changes made in the trunk to this feature
> branch, to stay them synced as the book suggests.

So you are doing, in a wc on ft_amazon_s3

  svn merge [url to trunk] .

? I make people paste commands into their commit messages because
sometimes what they do and what they did aren't the same.

> The problem is that, when
> i want to reintegrate the feature branch into the trunk, im getting errors
> as if some files were never merged into the feature branch. And that
> obvioulsy cannot happen because i just merge the last version of the trunk
> with the feature branch.
> The error looks like this.
>
> Error: Reintegrate can only be used if revisions 547 through 575 were previously
> Error: merged from
> https://bassobrovelli.springloops.com/source/bartrends/trunk to the
> Error: reintegrate source, but this is not the case:
> Error: branches/ft_amazon_s3/tests/fixtures/drink_ingredient_fixture.php
> Error: Missing ranges: /trunk/tests/fixtures/drink_ingredient_fixture.php:547-572
> Error: branches/ft_amazon_s3/views/drinks/edit.ctp
> Error: Missing ranges: /trunk/views/drinks/edit.ctp:547-572
> Error: branches/ft_amazon_s3/views/elements/logs_panel/entry_day.ctp
> Error: Missing ranges: /trunk/views/elements/logs_panel/entry_day.ctp:547-572
> Error: branches/ft_amazon_s3/views/layouts/default_1_column.ctp
> Error: Missing ranges: /trunk/views/layouts/default_1_column.ctp:547-572

You seem to have wrapped the error messages; I tried to fix that so I
could follow them. Here, it is not complaining about the contents of
megeinfo on branches/ft_amazon_s3, so presumably that's ok. Your real
problem is that you have subtree mergeinfo and you haven't articulated
why it should be present. svn 1.5.0 to 1.5.4 or so generated mergeinfo
From 'svn cp'. Once subtree mergeinfo exists it should be updated, but
this is hairy. Probably what is going on is that the root mergeinfo
(learn to love 'svn -R pg svn:mergeinfo ."!) is ok, and indicates that
everything from the trunk has been merged, but the subtree mergeinfo is
borked becuase of past history. So I would look at the mergeinfo, and
then on the feature branch manually remove all the subtree mergeinfo.

You didn't show the output of svn pg svn:mergeinfo on the files that
have subtree mergeinfo, but I bet when you look at it it will seem
wrong.

Also I advise you to prohibit merges at other than entire module level
(meaning you can svn merge a path that ends in trunk or branches/foo to
another such path, but not do merges of directories below that or
individual files). There shouldn't be any issue with cherrypicking
individual changesets, but merge them at the whole module level even if
they change only a few files deep down.

> But this is not the only problem, when im merging changes from trunk to
> feature branch, im always getting the same files updated, because all this
> files have the svn mergeinfo property, and they get the new commit revision
> number updated, so this could be an infinite thing, because everytime that i
> commit the changes in the feature branch merged from the trunk, the major
> revision number will increase and this files with mergeinfo property will be
> marked as diff in the next "merge".

It's true that the next merge from trunk to feature will update
mergeinfo to say that the revision (which just committed changes to
mergeinfo) is now merged, but it's not an actual problem. --reintegrate
will only fail if revisions not recorded as merged on the feature branch
touched anything in the parent branch. We have been doing essentially
what tou are trying to do and doing ok.

> So, there is a possible way to solve this, or i have to be attached to the
> normal merging (i dont know how the merge from the feature branch to the
> trunk could result), or maybe the best thing is to create a new empty
> repository and start everything again (all the history that im loosing if
> this is the solution make me really sad).

I would go on a rampage removing subtree mergeinfo.

Make sure everyone is running 1.5.6 or 1.6.2. I would ban anything
earlier than 1.5.6 and probably 1.6.0 and 1.6.2. That's probably more
strict than you need to be but why bother with bugs that might exist in
older veresions.

I hope this helps - I realize I'm overly presriptive about how to use
svn in these circumstances, but basically as long as the strict rules
don't hurt I think you're better off staying in safe territory and not
exercising the subtree mergeinfo code.

Also do svn diff from trunk to feature branch and see if you can explain
all the changes. Strange reverse changes may indicated things on trunk
that didn't get merged, and you may have to clean up.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2359102

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].