Mercurial Advice

[JamesMc86]

Hi,

I'm looking for some advice from anyone who has been using mercurial with LabVIEW.

Firstly I have just been trying some branching and merging. After a merge, having been configured for merge using https://bitbucket.or...iew-integration I see some .orig files getting left in the repository. Is this a failing on LabVIEWmerge.exe to clean it up or is it the way mercurial works?

I am interested in the DVCS camps because of merging. I currently use SVN, primarily as a lone developer. I like not having to maintain a separate central repo and the improved merging, primarily from the point of having sandbox branches. I like that in Git, if I have an experimental branch that doesn't work out I can delete it. Is there a similar workflow with bookmarks that can be achieved or am I going to end up with a load of bookmarks littered around the place?

I liked that Mercurial integrates better with Windows and is a simpler way to learn DVCS than Git, but I do also like the look of branching in Git and think the extra flexibility may be a killer feature. That said my general opinion when you get these 'holy wars' is that there is probably no real difference between them, else people wouldn't be arguing so much over minor details!

Cheers,

James

[Ton Plomp]

The .orig files are YOUR files from before the merge:

x.0----x.1------x.2

\----xa.1----/

x.orig is the x.1 file. Looking on Stackoverflow there are quite some posts about this file

Ton

[JamesMc86]

Ah probably should have started there. I realised what the files were but wondered who was to blame for them being left there. I would expect a system to clean this for me rather than me having to manually remove them.

It appears the purge extension may do this for you so I will investigate that further.

Cheers,

James

[Erik Disler]

Hi James,

 

I have been experimenting with mercurial. I have been using SVN for many years and have never been able to really do successful branching. It always involved lots of confusion and uncertaingy. That said, it still beats out any other tool I had used prior, such as PVCS and CM Synergy.  Fabiola de la Cueva  recently advised I try mercurial and so our team has been experimenting. Having used SVN for so long I must say that the distributed system model takes some getting used to, but I like the benefit of having lots of backups and the merging does seem to work better than SVN ( not exactly a high standard).

 

In my discussions with other LV architects and developers I think that mercurial seems to be the SCC  cream that is rising to the top. I am beginning to migrate some of my legacy code and new projects to mercurial. I have also started using an agile project management system that allows me to link mercurial commits to project tasks. 

 

I did some experimentation with GIT but I couldn't get the merge to work correctly. I intentionally introduced conflicts in LabVIEW vis . When I merged, GIT did not announce any conflicts when it should have. I didn't do a lot of testing after this and just decided to go with mercurial based on the input from other LV developers.

[JamesMc86]

Hi Erik,Thanks for sharing your experience. It is interesting to hear about Git as I reached a similar conclusion. The windows clients all had some holes in them and I got to the point where without a clear benefit to the technology, mercurial was simply easier to install, configure and use for Windows & LabVIEW.Cheers,James