2009/6/3 Greg Troxel <gdt_at_ir.bbn.com>
>
> 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.
That's the way im working now.
Work on trunk. When im ready to release, branch. If i have bug fixes, i
correct them in branch, and then i merge them to trunk.
If i have to develop a new feature thats is going to break the trunk, i
create a new feature branch, for example ft_amazon_s3. Being synced with the
trunk one time per day, and with the idea (i cannot make this work, thats
the reason of this mail!) to reintegrate it when its finished.
>
> > 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 work with tortoise svn, but yes, in the wc of the feature branch, i make a
merge pointing to the 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.
That's true, if i look into the mergeinfo prop, i have odd things, for
example in a directory that was created in the trunk and then merged to 0.9,
the mergeinfo has a lot of things of branches/0.3, 0.4... branches where
itself didnt exists... weird.
I think as a possibility to remove al that mergeinfo, but i didn't know if i
could break something important when commiting. I will give that a try.
>
>
> 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.
>
>
>
Thanks really really a lot. Im going to remove all the merge info that is
bothering there.
Thanks again,
gonzalo
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2359152
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-03 19:50:10 CEST