Which files to ignore using SCC

[Ton Plomp]

I'm about to move to a new SCC system and want to do it right from the start, one of the things I am always a bit fuzzy about is which files to ignore when using SCC.

I have the opinion that compiled code should not be inside an SCC, so I think about ignoring the following files:

• built*\
  
• *.ogp
  

Apart from that I think the followin LabVIEW specific files should be ignored:

• *.lvlps
  
• *.aliases
  

Any other opinions/ideas?

Ton

[jgcode]

I'm about to move to a new SCC system and want to do it right from the start, one of the things I am always a bit fuzzy about is which files to ignore when using SCC.

I have the opinion that compiled code should not be inside an SCC, so I think about ignoring the following files:

• built*\
  
• *.ogp
  

Apart from that I think the followin LabVIEW specific files should be ignored:

• *.lvlps
  
• *.aliases
  

Any other opinions/ideas?

Ton

I am of the same school of thought as you, for my applications I do not include my dist (build) folder into SCC.

However, I do have a zip (archive) folder where I will store deliverables that are milestones (released to the client). Usually this is a zip file containing files for a CD installable.

For my reusable code I also do not include the dist folder, but I will checkin my .ogp and .vip packages in my zip folder if they are releases (not for internal testing).

As for the project, I too, do not bother with the .lvlps and .aliases files as they seem to get regenerated on .lvproj launch just fine.

I also do not include any test files that get generated during (manual) testing, although I am conscious that removing these from under my SCC tree would make it a little cleaner.

[Yair]

Have a look through the LV help. It details which files are specifically designed to be ignored by SCC. If memory serves, these are the only two files in that list, but there might be others.

[Ton Plomp]

Have a look through the LV help.

Do yo know how much help there is with LabVIEW?

Anyway, the section is called LabVIEW file extensions.

And it lists indeed lvlps and aliases.

Ton

[jgcode]

Do you other people archive their exes/packages in their SCM?

I have read this can be deemed bad practice - you should only check in non-generated files.

[Daklu]

Do you other people archive their exes/packages in their SCM?

I have read this can be deemed bad practice - you should only check in non-generated files.

I don't, but I wouldn't call it "bad practice." I think there are valid reasons why one would check in built code in a distributable format, be it exes, installers, or packages.

I do make sure to check in any files associated with building a project. Specifically, OGB and OGPB files are included in my project and checked in to source control. We also have our distributable code hosted on an internal web site with a 14 day backup, so we don't have to rebuild them if somebody needs to reinstall it.

[GregSands]

Do you other people archive their exes/packages in their SCM?

I have read this can be deemed bad practice - you should only check in non-generated files.

So we can't check VIs in then?

There's a fine argument that VIs shouldn't store the compiled code in the same file.

[jgcode]

I don't, but I wouldn't call it "bad practice." I think there are valid reasons why one would check in built code in a distributable format, be it exes, installers, or packages.

I do make sure to check in any files associated with building a project. Specifically, OGB and OGPB files are included in my project and checked in to source control. We also have our distributable code hosted on an internal web site with a 14 day backup, so we don't have to rebuild them if somebody needs to reinstall it.

Cool, so you got no worries separating the archive from the code? I thought it would be nice to keep it all together in the one place per project. But the reason I ask about 'bad practice' is I can see some problems with it and was wondering if they is a better way!

What I am looking at is to try clean out the code project line so it is just code and code documentation. So I could branch a whole project, and it would make sense. Because obviously I don't want to branch exes etc... (they are there to get backed-up and retrieve if needed) and I don't want to branch my project stuff (knowledge base, timesheets, project management files etc...)... but I like having revisions of it and (at the moment) I like it being with the project.

So at the moment my folders for a project are like this:

<Repository>\<Client>\<Project> - <main-dev> this is my code line

<Repository>\<Client>\<Project> - <rev1.0> if I need to branch

<Repository>\<Client>\<Project> - <project management>

<Repository>\<Client>\<Project> - <knowledge base>

<Repository>\<Client>\<Project> - <archive> deliverables (e.g. exe's)

etc...

...So my next question is how to people manage their documents?

Do you use the same SCM provider as that as your code?

How do you store it (folder structure) etc... relative to your code

I am not looking for examples on how a repositry is managed (by versions vs by project etc..) but more on what do you do with non-code files (documents etc...)

[Black Pearl]

I exclude the exe's from my repository, but I consider it a valid practice to do so. (disc space is cheaper than the time lost just in case I had to get that old exe!).

All the documents go into SCC. External documents won't get changed, so that isn't important to have them under SCC. But design documents (they might not only relate to code but also to electronics, mechanics), roadmaps, user manuals, screenshots are all subject to change, hence they should be SCC'ed.

Felix

[jgcode]

I exclude the exe's from my repository, but I consider it a valid practice to do so. (disc space is cheaper than the time lost just in case I had to get that old exe!).

All the documents go into SCC. External documents won't get changed, so that isn't important to have them under SCC. But design documents (they might not only relate to code but also to electronics, mechanics), roadmaps, user manuals, screenshots are all subject to change, hence they should be SCC'ed.

Felix

Hi Felix

How do you structure your folder hierarchy for your SCC'd documents in relation to your code?

And where to your external documents sit as well?

[Black Pearl]

I'm still experimenting with the folder structure. This is how it might look using SVN on a local machine:

ProjectRoot:

|Repository

|Build

|Working Directory

And the Repo get's checked out to the Working Directory (Build contains the exe that is not under SCC)

And the Working Directory (in sync with the repo):

|Code

|External Documentation

|Internal Documentation

|Recources

Code documentation such as State Machine Diagrams go in the same location as the code.

As said, I don't have this set as a fixed pattern yet, and it is neither consistent among my projects.

Felix

[ASTDan]

Do you other people archive their exes/packages in their SCM?

I have read this can be deemed bad practice - you should only check in non-generated files.

I don't put my .exe in SCC. I do however tag the code that was used to build the exe. This way I can easily look at the state of the code that corresponds to that built exe version.

[Daklu]

Cool, so you got no worries separating the archive from the code?

I think it's too early and my brain isn't fully switched on--this question isn't compiling.

...So my next question is how to people manage their documents?

All our software is for internal customers and used to support product development efforts. Our requirements are very different than those of a professional Labview contracting shop, especially when it comes to documentation. Our scc directory structure is typically something like this...

<project>\trunk\source - application code

<project>\trunk\documents - documents another developer might need, such as instrument manuals, design documents, etc.

<project>\trunk\resources - stuff that is related to the project but is not Labview code. I'll put ogb and ogpb files here, as well as icons, config files, report templates, etc. We're looking to get a professional installer creation tool and those files will go here too.

We don't store customer-facing documents or project management stuff in source control. We use a Sharepoint server for that. Each project gets its own page on our release server where we post the installer as well as any installation instructions, required 3rd party applications, and user manuals.

Edited March 23, 2010 by Daklu

[jgcode]

I think it's too early and my brain isn't fully switched on--this question isn't compiling.

Funny!

Sorry I mean: I (currently) like having the archive (of builds) under the project folder along with the source code, documents etc. Your method is different, but I was asking if there are any cons of having it separated? But you went into more detail below.

All our software is for internal customers and used to support product development efforts. Our requirements are very different than those of a professional Labview contracting shop, especially when it comes to documentation. Our scc directory structure is typically something like this...

<project>\trunk\source - application code

<project>\trunk\documents - documents another developer might need, such as instrument manuals, design documents, etc.

<project>\trunk\resources - stuff that is related to the project but is not Labview code. I'll put ogb and ogpb files here, as well as icons, config files, report templates, etc. We're looking to get a professional installer creation tool and those files will go here too.

We don't store customer-facing documents or project management stuff in source control. We use a Sharepoint server for that. Each project gets its own page on our release server where we post the installer as well as any installation instructions, required 3rd party applications, and user manuals.

Ok, looks like your layout is similar, and we do, do System Integration (you pointed out that you don't).

I keep the stuff you mention with the application code. Essentially anything that is required to create the installer (which is usually the final product). Because usually the (NI) installer needs to point to config files, icons etc... (sometimes user manuals if they are installed). Everything thing else sits a layer up and is project management stuff.

This is unless a project (or release) is under our internal library - then the final product is a package (.ogp/.vip) and there is no project management.

I don't put my .exe in SCC. I do however tag the code that was used to build the exe. This way I can easily look at the state of the code that corresponds to that built exe version.

Me too. But I like to keep an archive of releases so I can get to them easily/quickly (or maybe I am lazy)

Its great hearing what others do. Keep it up!

[Daklu]

Sorry I mean: I (currently) like having the archive (of builds) under the project folder along with the source code, documents etc. Your method is different, but I was asking if there are any cons of having it separated?

Cons? Well, since I haven't ever had to go back and do anything with the exes or installers from previous builds (other than point people to their location) I haven't run across any cons. What advantage do you get by including the build output as part of the project?

[jgcode]

Cons? Well, since I haven't ever had to go back and do anything with the exes or installers from previous builds (other than point people to their location) I haven't run across any cons. What advantage do you get by including the build output as part of the project?

Well when I started here, that what was done.

Aside from the fact everything is together I can't think of any.

Hence, my reason to question... is it 'bad practice' / is there a better way?

[Daklu]

Well when I started here, that what was done.

Ahh... sacred cows make the best hamburgers.

(Of course, that assumes you survive the lynch mob that forms after you slaughter the sacred cow.)

[jgcode]

Ahh... sacred cows make the best hamburgers.

Its time to start hunting...