LabVIEW
Version Control
Hi
Andrey's observation of missing integrated support for recent SCC's is quite telling about NI's interest in this area.
There was a time when NI was very active. See :
Elijah made this impressive push in 2010 to 2013, but then seemed to run out of air :
NI is still struggling with Diff and Merge.
I would prefer to avoid that problem using file lock'ing which however is not used in modern SCC's by default.
Google AI states this about the situation :
- SCCS (Source Code Control System): The original 1972 tool that forced a single user to lock a file during checkout to prevent concurrent modifications.
- RCS (Revision Control System): Built as an improvement to SCCS, it similarly utilized file locking during checkout.
- Microsoft Visual SourceSafe (VSS): Depended heavily on exclusive file locking by default during a check-out.
- PVCS (Polytron Version Control System): Used a strict locking design where checked-out files were locked against other updates.
- Rational ClearCase: Enforced pessimistic check-out locks to restrict editing to one developer at a time.
NI themselves used Perforce in the old days.
SVN can enable file locking on demand.
GIT is handy to track VI changes using a nice GUI like SourceTree from Atlassian ( there are others ).
You can see when you made changes although you cannot ( in practical terms ) see what was changed.
And thanks to Yamaeda for pointing to the -VERY- old LabVIEW file saving concept which still do support sensible VI re-naming for versioning as prompted whenever we save a VI :
For what it is worth then selecting two VI's for comparison is easy with that name versioning concept.
Regards
@BertMcMahan wrote:
We used SVN for several years and have recently begun making the switch to Git. It's been "clicking" a lot better for me than I thought it would, and I like it a lot better. I used TortoiseSVN, but now just use Git via the command line.
I have TortoiseGIT installed, but i don't user it currently.
@Bob_Schor wrote:
@Yamaeda wrote:You save the VI with a new name each time, so you have Main.vi, Main2.vi, Main_new.vi, Main_newnew.vi, Main_forreal.vi, Mainv3.vi and so on ... or not.
I hope you realize that @Yamaeda is not being serious! Along with @GertW, I've also been using SVN for about two decades. Their tutorial is pretty good, and there's even a paperback book on an earlier version (I've got it somewhere ...).
I thought the "or not" gave it away. 🙂
@softball wrote:
Elijah made this impressive push in 2010 to 2013, but then seemed to run out of air
If I have the timeline correct in my head, Eli got a new position which is why this effort ran out of air. He was also quite successful in convincing the community to start thinking about SCC.
@softball wrote:
Early and Traditional Lock-Based Systems
- SCCS (Source Code Control System): The original 1972 tool that forced a single user to lock a file during checkout to prevent concurrent modifications.
- RCS (Revision Control System): Built as an improvement to SCCS, it similarly utilized file locking during checkout.
- Microsoft Visual SourceSafe (VSS): Depended heavily on exclusive file locking by default during a check-out.
- PVCS (Polytron Version Control System): Used a strict locking design where checked-out files were locked against other updates.
- Rational ClearCase: Enforced pessimistic check-out locks to restrict editing to one developer at a time.
You are reminding me of the nightmares of using PVCS back in the day. I was so happy when I convinced people to let me use SVN in a non-official capacity to keep my development racks in sync and then occasionally update what was in PVCS. It literally saved me a day per week by putting the racks on a private network and have then use a shared folder as the SVN server location.
@Yamaeda wrote:
@BertMcMahan wrote:
We used SVN for several years and have recently begun making the switch to Git. It's been "clicking" a lot better for me than I thought it would, and I like it a lot better. I used TortoiseSVN, but now just use Git via the command line.
I have TortoiseGIT installed, but i don't user it currently.
Yeah, after I started using the command line, I didn't feel the need to install TortoiseGit. For whatever reason, my brain "understands" what I'm doing a little better when I just use command line arguments than using the GUI. It only took a day or so of playing with it for me to get comfortable with Git's command line interface, and now I'm just as quick (probably quicker) than I was with the TortoiseSVN GUI.
@BertMcMahan wrote:
@Yamaeda wrote:
@BertMcMahan wrote:
We used SVN for several years and have recently begun making the switch to Git. It's been "clicking" a lot better for me than I thought it would, and I like it a lot better. I used TortoiseSVN, but now just use Git via the command line.
I have TortoiseGIT installed, but i don't user it currently.
Yeah, after I started using the command line,
Yes, I also use the Git command line and GitHub Desktop.
However, one feature that I miss when working in a team, especially when multiple engineers are working on the same project, is file locking, which prevents multiple users from checking out the same file for editing at the same time:
What I particularly liked about Microsoft SourceSafe was its integration with LabVIEW IDE. It allowed me to see directly within the project which files were currently checked out by other users (and by me myself with other icon). This made it easy to know who was working on what and helped avoid editing conflicts.
