Source Control Software (SVN, Perforce, Git, etc)

[Yamaeda]

---

@aputman wrote:

  Fabiola does say in the article that once someone has tried Git, they will never want to go back to SVN.  So I think I'm leaning that way for now but I'm still open to other's comments.

---

As a user of both, so far i'm not onto the GIT hype train yet. It does have some really nice features, but as is often the case, this comes at an increase of complexity. It's e.g. quite nice to be able to do several checkins (or pushes to use git vocabulary) even when offline and then Commit all the changes at once to a central server. If you're always connected to your repo, like if you're having it on your local computer, it just adds a step and Subversions direct Checkin is leaner.

So i would rather say the opposite, start with Subversion since it's a little more direct, and if you get into a multideveloper project spread geographically then transition to GIT. 🙂

/Y

[aputman]

Are projects typically stored in the same repository?  Is there a reason to have multiple repositories or is there a scenario where multiple repositories would be useful? 

[ShockHouse]

That part is up to you.

The way we do it is all of the projects local to our company, as well as common code we share is in one repo.

While all the projects and code local to a company we are doing work for is in its own Repo.

That way their trees/history are different than ours. And if we ever need to share the code developed for them, they don't get all of our other stuff.

[Yamaeda]

---

@aputman wrote:

Are projects typically stored in the same repository?  Is there a reason to have multiple repositories or is there a scenario where multiple repositories would be useful? 

---

Yes, yes and yes. 🙂

1st is obvious, 2nd and 3rd depends on stuff, but e.g. at a customer we have different repo for different LV versions, if you have many projects you can imagine a separate repo per customer, it depends on how you need to organize stuff, so a slightly revised answer would be:

Yes, Sometimes, Rarely.

/Y

[Bob_Schor]

---

@aputman wrote:

Are projects typically stored in the same repository?  Is there a reason to have multiple repositories or is there a scenario where multiple repositories would be useful? 

---

One of the great things about the Forum and the LabVIEW Community is that, as frequently happens, there may be no "wrong" answers.

When I started with TSVN, I read the Intro material and learned about the trunk/tags/branches Tree Structure of Repositories, and the "One Project/Many Projects" choice one could make.  I chose the Many Projects version for myself.  For the most part, an SVN Project corresponds to a LabVIEW "Project" (as defined by a Project File), which is almost always contained in a single Windows Folder (with lots of sub-folders, typically).

I do have some "Catch-all" Projects/Folders, such as "B-Lab" (where I have several dozen "small examples" and "little Projects"), and and a "Utility" Project/Folder where I have LabVIEW-Version-Specific sets of code, waiting for me to finally build them into a VI Package (in my copious Spare Time).

The virtue of this method is that when I go to a new Machine to work on Project A, I just checkout Project A, and don't bring all the other (LabVIEW) projects that would have otherwise been in a single SVN Repository.  There may be a clever work-around to handle this, but using separate Repositories for separate LabVIEW Projects has worked so well for me that I've not seen any problem (for me) with this approach.

Your milage may differ.

Bob Schor

[Yamaeda]

---

@Bob_Schor wrote:

The virtue of this method is that when I go to a new Machine to work on Project A, I just checkout Project A, and don't bring all the other (LabVIEW) projects that would have otherwise been in a single SVN Repository.  There may be a clever work-around to handle this, but using separate Repositories for separate LabVIEW Projects has worked so well for me that I've not seen any problem (for me) with this approach.

---

It's really easy to just checkout one folder (typically a project root) if need be. 🙂

/Y

[aputman]

The only downside I see (based on my understanding) to multiple projects in one repository is that the entire repository is revved when something is committed....not just the individual project that you happen to be working on that day.  So keeping multiple projects in a single repository means that the log is going to have a mix of commits that are unrelated to one another.  

TSVN 1.12.1 has a Project Monitor.  I haven't tested to see what this does...maybe it somehow filters out log messages related only to a particular project.  If so, my point above is moot.  

[FlatCat]

Having worked with TSVN for about a week now, I qualify as an expert, right? 

I have about 10 major applications that I write and support (by myself), each of which is a project. What I have done is to make one repository for each of those projects. Those 10 repositories sit together in a folder on my computer, and that folder gets backed up to the cloud a couple of times per day. This way I can Commit each project independently. 

[BertMcMahan]

I'll add another vote for SVN, no LabVIEW integration, multiple repos (one per project, with a few multi-project "internal" repos).

I will admit to not having a great reuse method yet, but I am planning on doing some VIPM packages with reuse stuff ("when I get around to it ;)")

I used to have the LabVIEW icon overlays in the project manager, but found they were crashy and didn't help much, if at all. My standard commit workflow is Ctrl-Shift-S (Save All) or the Save All button in the Project, then right click the project name in the Project explorer, then Explore. That opens up an Explorer window, where I can go up a level to see the main folder which I can commit. It's wordy to type out, but it's like 3 clicks and takes 2 seconds.

I also put all of my development code in c:\dev\[project], which makes organizing simple. If I want to get to my dev folder, I typically use Windows key + R (open Run window) then type "c:\dev" then Enter. Now boom, here are all of my projects.

We use multiple repos in one server, and it's worked well for us. We keep multiple different types of data in our repos as well, not just LabVIEW, and so far I like SVN quite a bit.

[prettypwnie]

I would recommend doing one repo per project. There are definitely other opinions (as you see here), and one famous example is actually Google, which I heard keeps all of their code for the whole company in one repo. However, I assume they are really good about branching and never committing except on the proper branch, and then merging the branch in when finished developing, etc... For a more simple use case I think its easier to have multiple projects. That way even if you are working in the default/master branch, you will not see random commits from a coworker on a different project and have to merge. Though I guess if you are working alone maybe it doesn't matter.