[Geany-devel] Build-system merge

Lex Trotman elextr at xxxxx
Thu Aug 20 12:47:45 UTC 2009

More info below

2009/8/20 Lex Trotman <elextr at gmail.com>:
> 2009/8/20 Nick Treleaven <nick.treleaven at btinternet.com>:
>> On Thu, 20 Aug 2009 20:32:17 +1000
>> Lex Trotman <elextr at gmail.com> wrote:
>>> Ok, I am sure you know all this but I have been told that SVN is
>>> *very* picky about merge and re-integrate.
>>> Your branch working directory should be a *clean* checkout of the
>>> branch, merge with trunk and re-commit to the branch, don't change
>>> anything other than fixing the conflicts.
>>> Your trunk working directory should be a clean checkout and then merge
>>> --reintegrate the branch.  There *shouldn't* be any conflicts here.
>>> Then commit.
>> Don't know what --reintegrate is. What SVN version do you have? I have
>> 1.4.4.
> Gee looks like my auto updater is working, I have 1.6.3 dated 15 July 09 :-)
> --reintegrate is a svn 1.5 option

Version 1.5 stores a record of the previously merged revisions in the
branch so that you don't need to use the full syntax, but you do need
to tell it that you are merging the other way, hence --reintegrate

I think using a 1.4 client and a 1.5 server means that it forgets the
merge history and just makes one big change back into the trunk with
everything that is different in the branch.

>>> I have been told to not believe the documentation that says that you
>>> can use any old working copy lying around.
>> I've never had any problems.
> Half your luck ;-) remember I had the branch go unusable on me once
> before, thats why I was asking someone.
>>> And you don't want to have anyone committing to trunk whilst you are doing it
>>>  If you like I can do it since I'm in the opposite time zone from you
>>> (UTC+10) so no one is committing while i'm awake. :-)
>> I'll do it. I may make some changes to the branch first.
> Ok.
>>> With the exception of any new commits to trunk, the only conflict at
>>> the moment is ChangeLog since it always grows at the end and so
>>> changes overlap.  The merges I've done should have resolved any other
>>> conflicts.  We will have to wait and see if the merges that SVN did on
>>> autopilot cause any problems, I couldn't see any but thats *no*
>>> guarantee :-).
>> Not sure what you mean by autopilot. I always tell svn which revisions
>> to merge myself.
> What I mean is, SVN bases its merge on lines rather like patch and
> that, just because SVN thinks that the lines that have changed don't
> overlap and so doesn't signal a conflict, doesn't mean that the
> changes actually make programmatic sense when combined.
>> Regards,
>> Nick
>> _______________________________________________
>> Geany-devel mailing list
>> Geany-devel at uvena.de
>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list