Hi All,
I've merged trunk r4100 into the build-system branch, checked it builds and runs and committed it back to build-system
Do you want to reintegrate it into the trunk before any more changes are made to trunk that can upset the process?
The only conflicts are geany.html, but that should be re-generated anyway and ChangeLog which I manually edited to accept all changes. Of course its out of date order now, but that can be fixed by a script when its in trunk (if it matters.)
Cheers Lex
Ping ;-)
Now merged with 4110.
Can we make a schedule for doing the re-integrate as it takes time to keep merging.
Cheers Lex
2009/8/17 Lex Trotman elextr@gmail.com:
Hi All,
I've merged trunk r4100 into the build-system branch, checked it builds and runs and committed it back to build-system
Do you want to reintegrate it into the trunk before any more changes are made to trunk that can upset the process?
The only conflicts are geany.html, but that should be re-generated anyway and ChangeLog which I manually edited to accept all changes. Of course its out of date order now, but that can be fixed by a script when its in trunk (if it matters.)
Cheers Lex
On Wed, 19 Aug 2009 09:54:42 +1000 Lex Trotman elextr@gmail.com wrote:
Now merged with 4110.
Thanks.
Can we make a schedule for doing the re-integrate as it takes time to keep merging.
Yes, I will merge the branch in the next few days, and so long as I know how to resolve conflicts with trunk I will do that too.
Regards, Nick
Hi Nick,
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.
I have been told to not believe the documentation that says that you can use any old working copy lying around.
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. :-)
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 :-).
Cheers Lex
2009/8/20 Nick Treleaven nick.treleaven@btinternet.com:
On Wed, 19 Aug 2009 09:54:42 +1000 Lex Trotman elextr@gmail.com wrote:
Now merged with 4110.
Thanks.
Can we make a schedule for doing the re-integrate as it takes time to keep merging.
Yes, I will merge the branch in the next few days, and so long as I know how to resolve conflicts with trunk I will do that too.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 20 Aug 2009 20:32:17 +1000 Lex Trotman elextr@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.
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.
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.
Regards, Nick
2009/8/20 Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 20 Aug 2009 20:32:17 +1000 Lex Trotman elextr@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
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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
More info below
2009/8/20 Lex Trotman elextr@gmail.com:
2009/8/20 Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 20 Aug 2009 20:32:17 +1000 Lex Trotman elextr@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Nick, sorry for the serial posting.
My partner just came home & she said that there are problems mixing pre-1.5 and post-1.5 clients because the former won't create information that the latter require when merging. Where she works had problems with this until they understood the cause. This is most likely why the original branch you created with a 1.4 client was corrupted when I merged it with a 1.5 client. The manual specifically recommends against mixing client versions and recommends upgrading to 1.5.
Cheers Lex
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.
Regards, Nick
P.S. I'm sorry that creating the branch with an old svn version seemed 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.
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
On Tue, 25 Aug 2009 12:19:49 +1000 Lex Trotman elextr@gmail.com wrote:
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.
OK, thanks.
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.
No, I got some source files with many conflicts also: [nmt@localhost geany-build-system]$ svn st |egrep '^C' C src/build.c C src/keybindings.c C src/plugindata.h C src/filetypes.h C doc/images/pref_dialog_edit_completions.png C doc/images/pref_dialog_toolbar.png C doc/geany.html
The src/ conflicts were quite a lot, and each one should have just taken the branch version instead of conflicting AFAICT.
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.?
No, the trunk ChangeLog is for trunk only. There should be one entry describing all the changes in the merge, dropping any trivial commit messages.
Merge back to trunk worked ok, no conflicts though it took a couple of tries because sourceforge kept dropping the SSL link.
Yes, that's annoying.
Regards, Nick
2009/8/25 Nick Treleaven nick.treleaven@btinternet.com:
On Tue, 25 Aug 2009 12:19:49 +1000 Lex Trotman elextr@gmail.com wrote:
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.
OK, thanks.
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.
No, I got some source files with many conflicts also: [nmt@localhost geany-build-system]$ svn st |egrep '^C' C src/build.c C src/keybindings.c C src/plugindata.h C src/filetypes.h C doc/images/pref_dialog_edit_completions.png C doc/images/pref_dialog_toolbar.png C doc/geany.html
I got a long lecture on everything I *never* wanted to know about SVN the other day, to sum it up, merges can be very sensitive to the condition of the URLs being merged and the working directory, Kind of makes sense, merge is a diff and apply process and if you make a diff against one thing and apply it to something different its bound to get confused. :-) Problem is its hard to make sure everything is clean so I just squandered disk space on extra checkouts.
The src/ conflicts were quite a lot, and each one should have just taken the branch version instead of conflicting AFAICT.
Heh heh, thats what I thought when merging trunk to branch the first time and I wiped out Enrico's toolbar changes, oops!!
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.?
No, the trunk ChangeLog is for trunk only. There should be one entry describing all the changes in the merge, dropping any trivial commit messages.
Thats a pity I didn't know that before, I could have dropped the branch stuff while it was easy to find. I'm afraid I'm not sure how to separate it now?
Merge back to trunk worked ok, no conflicts though it took a couple of tries because sourceforge kept dropping the SSL link.
Yes, that's annoying.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 25 Aug 2009 21:45:12 +1000 Lex Trotman elextr@gmail.com wrote:
The src/ conflicts were quite a lot, and each one should have just taken the branch version instead of conflicting AFAICT.
Heh heh, thats what I thought when merging trunk to branch the first time and I wiped out Enrico's toolbar changes, oops!!
Mmm, but having merged trunk to the branch first it should have worked In Theory (TM). I guess it may have been because your merge 'knew' more about where the code had come from, who knows.
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.?
No, the trunk ChangeLog is for trunk only. There should be one entry describing all the changes in the merge, dropping any trivial commit messages.
Thats a pity I didn't know that before, I could have dropped the
Sorry, forgot to mention it.
branch stuff while it was easy to find. I'm afraid I'm not sure how to separate it now?
What about: svn merge -c -4120 ChangeLog
Regards, Nick
On Tue, 25 Aug 2009 12:19:49 +1000, Lex wrote:
Hey,
yay about the merge.
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.
Sorry, no. It's a pure Subversion problem if the clients are that incompatible. It doesn't happen that often that people create branches in our repository :). And I think this is something which should be communicated in Subversion, not in Geany.
Regards, Enrico
On Tue, 25 Aug 2009 22:43:41 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
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.
Sorry, no. It's a pure Subversion problem if the clients are that incompatible. It doesn't happen that often that people create branches in our repository :). And I think this is something which should be communicated in Subversion, not in Geany.
I agree this is Subversion's problem. But to avoid corruption in future, we could leave the creation of the branch to the branch 'owner', so the merge info is also created if their client supports it.
Regards, Nick
P.S. I am planning on upgrading my system to Debian, so that might be easier to apt-get upgrade than upgrading entire Fedora versions every 6 months.