incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Podling to use native git
Date Fri, 01 Oct 2010 23:07:29 GMT
Yup. The 1.5.x release introduced a feature called "merge tracking",
but you really want to use 1.6.x (where many merge tracking issues
were fixed/improved/sped-up). It remembers which revisions have been
merged into a given location in the repository. This means bringing a
branch up to date is easy: it just takes any revisions from trunk that
haven't (yet) been merged and applies them to the branch.

When the branch is ready, you merge back to trunk with the
--reintegrate switch. That takes any revisions on the branch which are
*not* those which came from trunk, and applies them onto trunk. ie.
just the work you did on the branch.

If you're getting conflicts, then maybe you missed the --reintegrate
switch? Something is going on because (of course) that is exactly what
the tracking is there to prevent.

It is important that everybody uses at least a 1.5.x client (and even
better if the server blocks earlier clients); otherwise, early clients
will not report the merge.


On Fri, Oct 1, 2010 at 18:00, Mark Struberg <> wrote:
> It seems that with 1.6 SVN did learn a bit about the 'git way' (apologize if it was even
earlier and has nothing to do with git). SVN now applies merges bit by bit it seems (tested
with 1.6.9). But I still have problems with intermediately merged projects (merging the trunk
into my branch ~ every 2nd day). Somehow I ended up having the same pieces in my branch and
in my trunk, but both got marked as conflict.
> Anyway, SVN is the way to go for now.
> LieGrue,
> strub
> --- On Fri, 10/1/10, Jochen Wiedmann <> wrote:
>> From: Jochen Wiedmann <>
>> Subject: Re: Podling to use native git
>> To:
>> Date: Friday, October 1, 2010, 9:48 PM
>> On Fri, Oct 1, 2010 at 11:44 PM, Greg
>> Stein <>
>> wrote:
>> > I do branches all the time in Subversion, and don't
>> see problems. We
>> > periodically update the branch from trunk, and when
>> the work is done,
>> > merge the branch back onto trunk. These are
>> straight-forward
>> > operations, so I don't understand where your pain
>> point is.
>> >
>> > If you could explain a bit, then that would be
>> helpful.
>> Just out of curiosity: If you pull in changes from the
>> trunk to the
>> branch, how do you merge the branch later on? I'd consider
>> the changes
>> a problem that have been done in both branches. (Unlike
>> git, which
>> "knows" about these simultaneous changes.)
>> Thanks,
>> Jochen
>> --
>> I Am What I Am And That's All What I Yam (Popeye)
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message