By Francois Normandin
As I've reported in the UI Tools support page, I've started migrating the open source code I still have on bitbucket (Mercurial-based repos) to Github.
I didn't think that it might be worth a specific topic until @LogMAN mentioned it. Personally, I'm moving my code to Github in the process. I know there are some reports of Hg-to-Git transitions not going so well when using sub-repositories, so please share your migration experience if you've had to jump into some hoops to get it done!
For all of you who still use Mercurial and host your open source and/or enterprise repos on Bitbucket, this blog post is worth reading:
I am playing with GitHub as a possible replacement for our current SCC tool.
Do you guys use Git or GitHub? What client app do you use? Any recommendations?
I am specifically leaving the topic scope open, so feel free to praise/rant/headscratch.
While creating a new a new repo in GitHub, I noticed there is not a template .gitignore for LabVIEW -- let's make one!
After contacting GitHub support asking the proper channel for submitting a .gitignore to their set of templates, i received the following response: "We have an open source repository, https://github.com/github/gitignore that we use to accept contributions for the gitignore templates. The way we accept new contributions is through pull requests" From the readme.md on that repo, "Since this repo includes a large and diverse number of programming languages, frameworks, editors, and ecosystems, it's very helpful if you can provide a link to information supporting your pull request" -- we will use this thread and public discussion as documentation and justification for LabVIEW.gitignore.
So, I went ahead and forked the repo and created a new LabVIEW.gitignore, found here: https://github.com/wirebirdlabs/gitignore/blob/master/LabVIEW.gitignore
Please, feel free to contribute to this thread, and once we've come to a consensus, hopefully GitHub will accept the Pull Request.
Here's the contents of the file right now:
# http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/lv_file_extensions/*.aliases*.lvlps How can this be improved?
I've recently started using Subverion + TortoiseSVN to manage the source code of LabVIEW projects and I'm now getting to the point where I don't really know what I should do ; untill I had no banches and just revisions and a couple of tags for shipped versions I could handle it.
Now I need to go further than that and manage a large project that consist in an EXE and 3 plugins. The EXE will be shipped to many customers and each customer will have different "flavours" of the plugins.
I'm not feeling confortable enough with SCC usage to decide how to manage this scenario. Multiple repos? Sub-repos (does it exist?), one repo and 1 branch per customer?
The whole source code sums up to about 2000 VIs.
The EXE and the plugins have subVIs in common (some that are user.lib and some that are part of the project).
Any advice greatly appriciated.
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!