LabVIEW
Labview, Source Code Control and Backup
Solved!
@paul_cardinale wrote:
I check in my work when I have a significant change in reasonably good shape. Time between check-ins can be as much as a week or more. So I frequently backup manually to a local drive that's physically different than my working drive.
I wish I had a week or so to make significant changes to my code. 😉
@Bob_Schor wrote:
I'm also a Tortoise SVN users with two different SVN servers (different projects, different "rules" for sharing the servers).
My "Rule of Thumb" for Commits (which, every once in a while, like "weekly", I forget, to my sorrow) is "Always Commit when you've made enough significant changes that if you screw up and make a mess of your code, recovering from "Bob's Memory" (instead of Subversion's) would be painful, time-consuming, and profanity-inducing. And always commit when you work on Computer A, and plan to continue on Computer B (like "home" and "work"). Of course a corollary of this rule is to "Start your session with an Update!".
Bob Schor
This is very similar to how I work. Of course, this only works if you are working on a branch, and not the trunk. You never want to break code on the trunk. But then, you should always be working from a branch and only merge working stuff back into the trunk. My mantra is, "Commit often!"
@paul_cardinale wrote:
@billko wrote:
@paul_cardinale wrote:
I check in my work when I have a significant change in reasonably good shape. Time between check-ins can be as much as a week or more. So I frequently backup manually to a local drive that's physically different than my working drive.
I wish I had a week or so to make significant changes to my code. 😉
Of course "significant changes" is subjective. I make many changes every day. Much of the time the my code is broken because some part or parts are under construction. I tend to check in when there aren't too many pieces held together with chewing gum. Mostly what I'm working on is a very large and very very complicated project. I'll be lucky if I can finish this year.
I don't know how Perforce works, but with git you could use a branch and when you had something you liked, use the --squash option to merge it.
That way your other branch could have a bunch of potentially broken commits, and you could have your main/master/trunk branch only hold your one commit a week of perfectly updated code.
Hi Francesco,
you can also set the "Separate…" option for older projects: it's a property of the project, available by right-clicking the uppermost entry in the rpoject item tree!
@GerdW wrote:
Hi Francesco,
you can also set the "Separate…" option for older projects: it's a property of the project, available by right-clicking the uppermost entry in the rpoject item tree!
To add a bit to GerdW's post:
It's not enough to simply tick the checkbox. This will only apply to VIs (and controls) made after you enabled that option.
To apply it to existing VIs and controls, you have to click on [Mark Existing Items...] and select the files that are "unmarked". Closing the window and saving the project (and all the files that were changed) will update all your VIs and controls.
