[Geany-devel] Build-system merge
elextr at xxxxx
Tue Aug 25 02:19:49 UTC 2009
2009/8/25 Nick Treleaven <nick.treleaven at btinternet.com>:
> On Thu, 20 Aug 2009 12:05:12 +0100
> Nick Treleaven <nick.treleaven at btinternet.com> wrote:
>> > 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.
>> > 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.
> Sorry for the delay. I've made the changes I wanted before merging. I
> just tried the merge and it seemed to go OK except there were some
> conflicts - so actually if you don't mind doing it, please go ahead.
> I'm not sure why there are conflicts.
I did it exactly as per the recipe I mentioned in a previous email.
The only conflicts I got merging trunk to build-system were
plugindata.h where you had bumped the api/abi versions, so I took the
higher versions and changelog which as I explained previously always
conflicts if there are changes in both trunk and branch since all
additions are at the end and so overlap line numbers.
ChangeLog probably needs to be checked that it has everything. It
currently is in the order of merges between branch and trunk, I'm not
sure if it should be re-sorted to date order, easier to find changes
but loses the merge history.?
Merge back to trunk worked ok, no conflicts though it took a couple of
tries because sourceforge kept dropping the SSL link.
Builds and runs, thats about as much as I tested it. (I like my new
quad core box, full Geany build & install <30 secs :-D )
Re-checked trunk out & confirmed build & run.
> P.S. I'm sorry that creating the branch with an old svn version seemed
No fault, neither of us knew.
> to cause the earlier corruption you saw, but I don't really see why they
> can't fix this in a newer version rather than tell older client users to
> upgrade. Obviously there wouldn't be the merge info, but it certainly
> shouldn't cause corruption IMO.
I agree if there was a way to do it
But.... if a new client knew that a merge was done by an old client it
would be able to compensate for the missing mergeinfo or refuse to
merge, but as the old client doesn't write mergeinfo the new client
doesn't know that an old client did a merge, it just sees another
commit, so it can't compensate or refuse to merge or anything...
The merge probably would have been ok if I had specified versions like
you do, but I had no idea that I needed to :-S I just read the book!!
Maybe should be mentioned in hacking so new people like me know that
old svn versions may have been used so don't rely on the mergeinfo.
I did this merge with versions and no problems. The upgrade to svn
1.5 was so that versions didn't have to be specified because users
will always get them wrong :-)
One of the advantages of the recipe is that the version is the same
for branch and trunk after trunk has been merged to branch so its a
little bit easier.
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel