SCC : From SVN to Mercurial or Git ?

[Zyl]

Hi !

I know that there are numerous threads about SCC, but none really helped me to answer clearly this question : I want to move from SVN to a DSCC to be able to commit even if I cannot connect to my server, which DSCC should I use between Git and Mercurial AND how should I set it ?

I use SVN for years now, and I always apply the same rules to be able to work with several developpers on the same projects :

• Files are all locked, a developper MUST unlock them to work on them
• Locked files are read-only
• LabVIEW is set to treat read-only files as locked and not to save automatic changes (old habit to avoid LV to recompile and ask to a VI for non-functionnal 'modifications')

These settings work perfectly fine for us.

Can I replicate such settings with Git / Mercurial ? Is there a point to do it ?

I have a video from Fabiola explaining how she uses Mercurial with LV. One of her LV setting is to separate compile code from source code (I guess to avoid unnecessary changes made by the compiler when opening a VI for example to be taken into account by the DSCC). I've heard that this setting is sometimes buggy and generate more problems than really helping. Is it still true with new LV versions ?

Reading some comparisons between Git and Mercurial, I would tend to use Mercurial (seems easier to use, more particularly by SVN users). But Git seems to be more popular even in the LV community. Is there any specific reason (related to LV or not) to that ?

Thank you for your help and opinions !

 

Cyril

[hooovahh]

I've used Mercurial with LabVIEW in the past, I'd recommend you checkout the TortoiseHG which has similar explorer functionality you are probably used to in TortoiseSVN.

https://www.mercurial-scm.org/wiki/TortoiseHg

As for separating source.  This feature has been in place for several years, and while there could still be bugs with it, most of the initial problems problems people have had with it have been ironed out.  That being said I do sometimes still need to purge my compile cache to force things to work, but I think that issue could happen on non separated code as well.

As for the read-only locking functionality.  I remember having this but I don't remember how to configure it to behave this way.  But with DSCC I think the idea is to not need to first ask to get locks.  The intent is anyone can make changes and then push them to the repo as they need.  I have only worked with DSCC a couple of times, but I don't remember stepping on any other developers foot much.

[smithd]

I've never tried to lock any git or hg server so I can't help there, but I also absolutely hate that 'feature' of svn, p4, etc so...

I find that merge conflicts are rare unless your source is very tightly coupled or monolithic, and of course you can tell if its tightly coupled by how many merge conflicts you have

But really, you are the only one one who can determine if the merging will be an issue. If you find yourself very often going to your coworkers and saying 'hey unlock that thingy please!' you will absolutely have a bad time with git. If like me thats happened a few times per year, git works fine without locks.

Edit: might be worth checking out http://www.peterlundgren.com/blog/on-gits-shortcomings/ specifically access control

Edited September 27, 2017 by smithd

[Neil Pate]

I switched over to Mercurial from SVN about five years ago and have never looked back since. I work remotely to the rest of my teams and find the DVCS nature a very good fit. Actually it was a good fit even as a sole developer.

I use Bitbucket for hosting, very reasonable price for small teams (free!)

I use the TortoiseHg plugin for Windows, I usually version my entire directory which contains docs, source, builds etc. (Not installers though, they cause the repository to get big very quickly).

[Antoine Chalons]

I saw this recently, maybe it can help you make a choice :

source :

https://pbs.twimg.com/media/DKgjJXaU8AAqyhC.jpg:large

[smithd]

its difficult to trust a table like that. to specifically call out one obvious issue...if someone has a copy of your repo, no you cant control access. But the access control doesn't happen at git or hg, it happens at the server. All of those listed servers have reasonable access controls.

[Zyl]

Hi!

Thank you for all these answers.

 

Hooovah: Thank you for the precision on separating compiled code / source. however for some of our customers, we still use old LV versions (2010..2013). So I guess the issues can still be a problem for these projects.

Smithd : Locking on SVN helps a lot when working on big projects (I had once more than 10 developpers working on the same project) and it prevents headackes due to the merging process in LV. Since a locked file is read-only, and with LV well set, you don't get 'modified' VIs just because you opened them. Our rule is to unlock one by one the files to modify and to commit right after any modification is made, so that it unlocks the file rapidly. Locking issues with developpers is really rare. 

Neil : I plan to host the server on our Synology NAS, so everything stays 'in house'. For some of our customers it is (still) comforting to 'know' that the sources are not in the cloud. But I plan to use TortoiseHg as our client. Do you have any specific settings that you apply to your client ? To LV because you use Mercurial ?

Antoine: I've seen that too on Twitter. And it let me think that Mercurial would be a better choice than Git (mainly for the non-mergeable files and Trunk-base dev rate). But so many people rely on Git (even NI lately) instead of Mercurial. So I was thinking that there is a particular reason about it.

[Neil Pate]

Zyl, personally I trust Bitbucket and their IT staff with backing up my data way more than I trust my Synology NAS (which is great by the way, I have a two bay RAID1 setup and I use it as an additional backup device).

LabVIEW knows nothing about my VCS, I do not bother with locking or anything like that. The only setting relevant in LabVIEW is the separate compiled code which helps prevent the old problem of LabVIEW wanting to save 500 VIs just because a typedef changed.

Merging can be tricky but if you communicate things properly with the rest of the team and agree who gets to touch what I find it is generally not a problem. (Use Slack, it is a super tool).

[Zyl]

Thank you for your advices!

I'll go with Mercurial and my Synology !

[Stagg54]

On ‎9‎/‎27‎/‎2017 at 8:43 AM, Zyl said:

 

Smithd : Locking on SVN helps a lot when working on big projects (I had once more than 10 developpers working on the same project) and it prevents headackes due to the merging process in LV. Since a locked file is read-only, and with LV well set, you don't get 'modified' VIs just because you opened them. Our rule is to unlock one by one the files to modify and to commit right after any modification is made, so that it unlocks the file rapidly. Locking issues with developpers is really rare. 

Just curious how you manage that without committing broken code?

[Zyl]

On 10/10/2017 at 3:39 PM, Stagg54 said:

Just curious how you manage that without committing broken code?

We do commit broken code !

And we think it is important : the trunk is the 'ongoing' state of the developement. So it is normal that the code is broken if prototype or wrong code is delivered. If we cannot build and make tests with the code, there is no chance that a stable release will be tagged.

For the rest it only relies on team management and communication. But at least wit heth locking system and identified commit, we have a chance to know what is going on or at least who did it.

[Stagg54]

I'm glad that seems to work for you, but...

I think you will find the conventional wisdom on version control is that the Golden Rule is "Don't Commit Broken Code".

 

If 1 person checks in broken code, then when everyone else checks it out - if they want to run it, they have to fix what's broken.  If 10 different people check it out, then you have 10 different people trying to fix it in 10 different ways and then you have this huge merge problem...  Seems like a major headache.

If you use a distributed version control system like git or mercurial, you could do local commits of broken code and then only push once it is no longer broken.  That way you can save intermediate copies so you can roll back if needed, but no one else is going to check out broken code.

 

[ShaunR]

11 hours ago, Stagg54 said:

I think you will find the conventional wisdom on version control is that the Golden Rule is "Don't Commit Broken Code"

Indeed. In fact. I've worked at places where whoever breaks the trunk buys pizza for everyone.

The "wisdom" you speak of can be stated thus: "You can break a branch and the tree will still grow but if but if you break the trunk the whole tree dies". This is still true for distributed SCC where the staging is effectively an enforced branch.

There's a lovely description using the nature/tree analogy for SVN which applies, IMO, to all SCC.

Edited November 3, 2017 by ShaunR