Highlighted
Regular Contributor.
Regular Contributor.
82 views

Git vs. Subversion for SCM

I would be interested to hear from anyone using Git for SCM.  Previously we were using SVN, but the company has pretty much forced us to go with Git and it seems to handle things very differently.  In particular, handling a group of Content Packs as a "branch" rather than individual handling of Content Packs.  And not having the locking facility is a real problem for me.  Thanks.

2 Replies
Highlighted
Super Contributor.
Super Contributor.

Re: Git vs. Subversion for SCM

My company also moved from SVN to GIT.  It took some time to get used to the differences.   The one you mentioned about a "branch" and individual content pack takes a mind shift to get used to using.  Once you understand it and realize you can create new branches and as many branches as you need, you can come to a useful strategy.  One thing we use is to create a branch based on a content pack.    This is pretty much like working on a individual branch.  The big drawback is the way OO Studio handles GIT.  We have a lot of content packs and it can take a while for Studio to load or switch between branches.  Also, when switching between branches, not all the contact packs are displayed and you can't import them.  You have to restart studio, sometime even removing the entry from the settings.xml.  We opened an issue with Micro Focus, but didn't receive any help except move to the latest release and it "should help".

Watch out when OO loses it mind and brings in empty projects that were created in another branch.  It isn't supposed to have these unimported changes, but it does.  You can go to the local repository and delete the folder. 

Make sure you check the SCM Change tab before switches branches.  OO does have a message about changes when switch branches, but that shows up when there are uncommitted changes and when there aren't uncommitted changes, so that make the message box annoying rather than helpful.

Another big help is to use another GIT tool.  I use Sourcetree.   I sometime do my merges in Sourcetree, because it is way faster (doesn't have to update studio with each merge).  If there are conflicts, I bring it back up in studio to solve.  I haven't found a merge conflict tool to use yet and make available in Sourcetree.  Another use of Sourcetree is when updating my branches with the latest master.  Doing the merge in Sourcetree is way faster than Studio.  

I did wish OO provided Cherry Picking.   That would be a nice feature to have in OO.

 

0 Likes
Highlighted
Regular Contributor.
Regular Contributor.

Re: Git vs. Subversion for SCM

Thanks for your response, Bridges.  It was very helpful and I am glad to hear that I am not the only one in this situation.  It definitely requires a "mind shift" and I guess also requires some more patience from my side of things.

I don't like the idea of having a separate branch for each Content Pack, since we have (for our "product") about twenty interdependent Content Packs.  In the past we were able to easily handle the build numbers of each and therefore could say that a certain bug was fixed or enhancement provided in build such and such of a certain Content Pack.  It seems like we will have to work out how to version all builds of all Content Packs under a branch with the same version which requires editing the properties and pom files.

Anyway, you have given me a lot to think about.  Thanks again.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.