[Geoserver-devel] 2.2-RC3 artifacts on sourceforge, but tagging failed

GeoServer GeoServer Developer
1

Hi,
the GeoServer release scripts worked for the most part without modifications,
but I’m finding an issue at the very end of the release publishing script.
After uploading the artifacts to sourceforge it tries to tag the release on github,
but here is what I get:

Switched to branch ‘rel_2.2.x’
M src/community/python/geoscript
Auto-merging src/wms/pom.xml
CONFLICT (content): Merge conflict in src/wms/pom.xml
Auto-merging src/wfs/pom.xml
CONFLICT (content): Merge conflict in src/wfs/pom.xml
Auto-merging src/web/wms/pom.xml
CONFLICT (content): Merge conflict in src/web/wms/pom.xml
Auto-merging src/web/wfs/pom.xml
CONFLICT (content): Merge conflict in src/web/wfs/pom.xml
Auto-merging src/web/wcs/pom.xml
CONFLICT (content): Merge conflict in src/web/wcs/pom.xml

Hum… hu?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

2

Yeah, this is a known issue with the current way we structure release branches. Basically the way we branch from the main branch, update version numbers, and merge onto the release branch results in merge conflicts due to two commits that have updated version numbers. I thought the “theirs” merge strategy would fix this but it apparently does not really have an effect.

So long story short we need to rethink that. My first thought is to branch instead from the rel_2.2.x branch when creating the temporary release branch. The problem there is that we already have replaced the version numbers on that branch, as well as the date for the README, etc…

Another alternative I thought of was rather than tagging after all the version numbers, etc… are updated tagging before and forgoing to the merge of the temporary release branch back into the main one. The downside there is that the tag wouldn’t correspond to the exact version that has all the pom versions set, etc…

Anyways, open to suggestions on this. For now i can manually resolve the merge on the build server and push the new release branch and tag. Sound good?

-Justin

.

On Sat, Sep 1, 2012 at 10:13 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
the GeoServer release scripts worked for the most part without modifications,
but I’m finding an issue at the very end of the release publishing script.
After uploading the artifacts to sourceforge it tries to tag the release on github,
but here is what I get:

Switched to branch ‘rel_2.2.x’
M src/community/python/geoscript
Auto-merging src/wms/pom.xml
CONFLICT (content): Merge conflict in src/wms/pom.xml
Auto-merging src/wfs/pom.xml
CONFLICT (content): Merge conflict in src/wfs/pom.xml
Auto-merging src/web/wms/pom.xml
CONFLICT (content): Merge conflict in src/web/wms/pom.xml
Auto-merging src/web/wfs/pom.xml
CONFLICT (content): Merge conflict in src/web/wfs/pom.xml
Auto-merging src/web/wcs/pom.xml
CONFLICT (content): Merge conflict in src/web/wcs/pom.xml

Hum… hu?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

On Sun, Sep 2, 2012 at 3:22 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, this is a known issue with the current way we structure release branches. Basically the way we branch from the main branch, update version numbers, and merge onto the release branch results in merge conflicts due to two commits that have updated version numbers. I thought the “theirs” merge strategy would fix this but it apparently does not really have an effect.

So long story short we need to rethink that. My first thought is to branch instead from the rel_2.2.x branch when creating the temporary release branch. The problem there is that we already have replaced the version numbers on that branch, as well as the date for the README, etc…

Another alternative I thought of was rather than tagging after all the version numbers, etc… are updated tagging before and forgoing to the merge of the temporary release branch back into the main one. The downside there is that the tag wouldn’t correspond to the exact version that has all the pom versions set, etc…

How about branching to rel_, do the pom changes, build and so on, when we’re publishing push that branch to github, tag it, and then delete the branch?

Anyways, open to suggestions on this. For now i can manually resolve the merge on the build server and push the new release branch and tag. Sound good?

Yep. After a bit of fiddling the exact same problem is happening on geotools too

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

4

On Sun, Sep 2, 2012 at 1:09 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sun, Sep 2, 2012 at 3:22 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, this is a known issue with the current way we structure release branches. Basically the way we branch from the main branch, update version numbers, and merge onto the release branch results in merge conflicts due to two commits that have updated version numbers. I thought the “theirs” merge strategy would fix this but it apparently does not really have an effect.

So long story short we need to rethink that. My first thought is to branch instead from the rel_2.2.x branch when creating the temporary release branch. The problem there is that we already have replaced the version numbers on that branch, as well as the date for the README, etc…

Another alternative I thought of was rather than tagging after all the version numbers, etc… are updated tagging before and forgoing to the merge of the temporary release branch back into the main one. The downside there is that the tag wouldn’t correspond to the exact version that has all the pom versions set, etc…

How about branching to rel_, do the pom changes, build and so on, when we’re publishing push that branch to github, tag it, and then delete the branch?

Yeah this is worth a try.

Anyways, open to suggestions on this. For now i can manually resolve the merge on the build server and push the new release branch and tag. Sound good?

Yep. After a bit of fiddling the exact same problem is happening on geotools too

Odd… i just checked out the state of the repository and it seems it was somehow merged with master on the rel_8.1 branch. I rolled back to the HEAD state, checked out rel_8.x, merged rel_8.1 into it using the “-Xtheirs” merge strategy and it worked fine, no conflict to fix. Not sure how what happened here. Anyways, branch and tag manually pushed for now.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

On Mon, Sep 3, 2012 at 3:54 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Odd… i just checked out the state of the repository and it seems it was somehow merged with master on the rel_8.1 branch. I rolled back to the HEAD state, checked out rel_8.x, merged rel_8.1 into it using the “-Xtheirs” merge strategy and it worked fine, no conflict to fix. Not sure how what happened here. Anyways, branch and tag manually pushed for now.

Thanks!

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it