2009/8/25 Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 20 Aug 2009 12:05:12 +0100 Nick Treleaven nick.treleaven@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 )
Committed it.
Re-checked trunk out & confirmed build & run.
Regards, Nick
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.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel