move project to another PC

[Mark_Yedinak]

---

@Ben wrote:

RE: SCC ...

---

@Mark Yedinak wrote:

---

@battler. wrote:

Thanks everybody.

Mark, you must just be the telling off type.  

---

Not really. Just a strong advocate of doing things right.

(It's tough at times to come across the right way using a keyboard.)

---

In the interest of questioning all accepted standards I have to question...

So before SCC was invented we backed stuff up and kept track of our development forks just fine. There was no need for "nanny-code" forcing us to check stuff out and in etc (oops did I just reveal my heart re SCC?).

Was I doing thing WRONG bak then?

If I dislike SCC and get by fine without it, am I wrong now?

In the big picture I don't care for SCC being pushed as the only way to do it "right". It like football helmets just encorage people to take risks they would not take if they did not have SCC doing the data-police thing.

My beef is not with doing backups (meganointo may it not be so) but with this popular ... fable that "SCC or you are wrong".

So, is the emporor realy naked?

Ben

---

As an interesting war story from the old days the first company I worked at had not fully begun using SCC. Our network guy game in to run the weekly back up and as he was watching the status of the back up he thought something had gone terribly wrong. He saw basically the following information:

Backing up \zoo

Backing up \zoo\zoo

Backing up \zoo\zoo\zoo

Backing up \zoo\zoo\zoo\zoo

Backing up \zoo\zoo\zoo\zoo\zoo

This continued quite deeply (over 10 levels deep). As it turned out this this developer's backup method was to keep duplicating his code and storing it one level down. You could imagine how this would get very difficult to manage after a while.

With respect to your dislike of SCC I would say that if you are a one man shop you can get away without using it much more easily than in a large team development. SCC control provides many tools besides just keeping copies of code. If you don't use it do you really want the entire team trying to check for conflicts in code check-ins manually? It also formalizes the process which makes it easier for the team to operate. It would be chaos if everyone had their own method of doing things. Just because something worked in the past just fine doesn't mean advances in methodoligies should be ignored.

Pumping your brakes was the accepted method of stopping on snow and people considered that to work "just fine" too. Should we avoid using ABS brakes?

[Ben]

---

@Mark Yedinak wrote:

---

@Ben wrote:

RE: SCC ...

---

@Mark Yedinak wrote:

---

...

With respect to your dislike of SCC I would say that if you are a one man shop you can get away without using it much more easily than in a large team development. SCC control provides many tools besides just keeping copies of code. If you don't use it do you really want the entire team trying to check for conflicts in code check-ins manually? It also formalizes the process which makes it easier for the team to operate. It would be chaos if everyone had their own method of doing things. Just because something worked in the past just fine doesn't mean advances in methodoligies should be ignored.

Pumping your brakes was the accepted method of stopping on snow and people considered that to work "just fine" too. Should we avoid using ABS brakes?

---

If they encorage riskier driving then yes.

I regulary work with groups of developers and we will switch off to the flavor of SCC demanded by our customers so I am aware of what we get from SCC... amoung other things, a paper tril to prove who screwed it up.

I must confess that I do prefer to work without the data-police telling me what to do.

I am not going to try and push you to say "uncle".  I am just starting my own version of the Chinese water torture* and this is the first (or second) drop.

Thanks for playing along!

Ben

*It worked for locals so why not try it again?

[Darin.K]

I need go no farther than a mirror to know whom to flog for bugs in my code. My style predates many of the modern stylings of LV (libraries, projects, SCC, OOP) which strike me as helpful if you are prone to do the mistakes they are designed to prevent. The situations where they add value are limited, so the ideal situation would be to use them when helpful and skip the overhead when not necessary. The most important step I take IMO is to keep my file hierarchy well organized and matched to the underlying VI hierarchy. This makes it easy to find and reuse code and also makes backup and transfers easy. This also facilitates the two tools I use all the time DropBox and SyncToy. In lieu of SCC these two tools let me have synchronized versions of all of my code anywhere, and all of these copies are extra backup protection. DropBox also gives me access to limited revisions to recover from the seldom Ctrl-S fiasco. A near seamless backup and SCC for the single user.

[Ben]

---

Darin.K wrote:
I need go no farther than a mirror to know whom to flog for bugs in my code. .... A near seamless backup and SCC for the single user.

---

So I can increment the "We don't need no stinkin SCC" column for Darin.

That double the previous count.

Ben

[smercurio_fc]

Well, it certainly was never my intention to start an SCC holy war. It just seemed to me that doing a checkout from SCC was a very simple solution - you didn't need to create a build or a File -> Save whatever operation. Hence the reason for suggesting it in the first place.

However, let the crusades continue!

[Mark_Yedinak]

---

@Ben wrote:

---

@Darin.K wrote:
I need go no farther than a mirror to know whom to flog for bugs in my code. .... A near seamless backup and SCC for the single user.

---

So I can increment the "We don't need no stinkin SCC" column for Darin.

That double the previous count.

Ben

---

One could argue Ben that you and Darin are using a source control system, albeit a roll your own variety. Darin described a fairly formal methodology he uses to backup and track changes to his code. Granted he is not using a specific CM tool to do the job but he is performing the basics of a SCC system. You also stated you keep regular backups and versioning of your code.

So you can increment the "We don't need no stinkin official SCC" column.

[Ben]

I'll go with that.

Ben

[Bob_Schor]

Speaking only for myself, I cannot imagine how I kept track of my code before (Tortoise) SVN!  I try to (remember to) commit every time I make a change that I intend to "keep" (if I'm only "testing", I might change, test, then revert).  Moving to another computer is then simply "Checkout", and starting out the day I simply "Update" (assuming I did some work from home).  Best of all, if a week down the road I realize "Oops, this was a bad idea ...", I can go back to a previously-saved "entire project" and continue from there.  It really has been a boon to me.

Bob Schor

[battler.]

What about dependencies?  You can not usually file all those.

How does SCC work with LV dependencies (i.e. OpenG)?  How can I include them all then check out on another PC?

[Ben]

---

@battler. wrote:

What about dependencies?  You can not usually file all those.

How does SCC work with LV dependencies (i.e. OpenG)?  How can I include them all then check out on another PC?

---

OpenG has their own sceme for keeping track of code.

Other dependencies are an issue when I introdcue them to the app. Specificaly the stuff that want to go in user.lib would complicate my life so I don't use them from there. If the code is good enough to actually go through the trouble to use I go through each add-on one by one and save them into the project folder.

An old habit I picked form back in the day of cross-linking issues, I show the full path in the VI hiarchy screen and float over everything to make sure ALL of the dependencies are in sub-folders of my project. Yes its a pain but well worth it.

1) When I backup my source code I am backing up ALL of my source code.

2) Years latter when the customer calls to say the machine went bad and they don't have a back-up, I do an it is complete all the way down to those extra thingies.

3) When my work load requires I share my projects, the developer in the next cube just has to grab the most recent zip and they have exactly what I have on my machine.

Well that's my 2 cents,

Ben