Building an installer deletes SVN files

[crelf]

I've been having an issue with building installers screwing with my local SVN files. Say I build an installer, and then add/commit all of the generated files to source code control. Then, the client wants a change, so I lock all my installer files, and rebuild. The LabVIEW installer *deletes* the files and folders in the target location and creates new ones. That's where the issue begins: the LabVIEw installer not only deletes all the previous built files, but also all the SCC files in their folders, so Tortoise/SVN gets awfully upset and complains about orphan locks (essentially missing local files). I assume that this is also an issue with other SCC providers that have local hidden files to keep track of things. Bug, or feature? This method of building/SCC has been around for a long time - how do you all get around it?

[Mark Smith]

I avoid this problem by not including my installers or exe's in the source code repository. If you version the project (which includes all the build info for the exe/installer) then you should be able to rebuild that version of the exe/installer any time you need one. With that said, I still move my released installers to another directory, zip them up with version numbers in the file names, and then commit them. This insures I can quickly supply a new installer to a customer and avoids the hassles you have encountered.

I do think this is a common problem - I've learned not to include any of the auto-generated stuff (all of the debug databases, object code, support files, etc) from my VS projects, either. If I did want to keep certain items, one way around this in VS is to include a post-build script that copies the files to a location where the compiler or install build won't touch them, and then version control that folder.

Also, not including installers really helps my commit/update times when I'm at a remote site and on a slow connection!

Mark

[crelf]

QUOTE (mesmith @ Jan 12 2009, 06:03 PM)

I avoid this problem by not including my installers or exe's in the source code repository. If you version the project (which includes all the build info for the exe/installer) then you should be able to rebuild that version of the exe/installer any time you need one.

Thanks for the great comments Mark. I had thought about not including installers in SCC for that very reason, but we work in regulated industries where rebuilding something (even if we can proove that nothing has changed between builds) isn't something that we can do

It's good to know that I'm not the only one with this issue :thumbup:

[xtal]

QUOTE (crelf @ Jan 12 2009, 07:27 PM)

It's good to know that I'm not the only one with this issue :thumbup:

I'm in the same boat as you are, Chris. Regulated industry and everything. Luckily for me, we just switched to SVN from VSS. Now I know what to look out for.

Good luck.

[Justin Goeres]

This has been a problem for me, too, for a long time. I eventually just gave up and stopped including installer directories in SVN. If I need to commit something, I commit a zip file of the installer.

However, this topic reminded me that a similar problem exists when using Keynote (or Pages) on a Mac with SVN-controlled documents. Namely, that Keynote (or Pages) blows away all the .svn folders when it saves a file (this is not technically a bug for reasons that are beyond the scope of this board, let alone this thread ). A while back, Omar pointed me to a script that restores the missing .svn stuff that has solved that problem for me. It's a OS X(/Linux/Unix) shell script, but it could be pretty easily replicated in a Windows batch file.

I don't recall exactly how it works, but the sequence of operations is essentially this:

1. Find the target directory's location in SVN.
   
2. Do an export of just the SVN metadata from that branch of the tree to a temp location. (I'm guessing at this -- it definitely doesn't take long enough to be doing a full export from scratch)
   
3. Copy all the SVN metadata you just exported from its temp location into the target directory. This recreates the missing .svn's.
   
4. Delete the temp files.
   

When it's done, voila! The .svn folders have magically reappeared and all is right with the world. In the case of Keynote/Pages, I just run the script after I save and before I commit. It's a minor hassle, but one I can live with.

[crelf]

QUOTE (xtaldaz @ Jan 12 2009, 07:16 PM)

Luckily for me, we just switched to SVN from VSS. Now I know what to look out for.

I used to use VSS a few years ago, and it pretty-much sucked I do really like the subversion and Tortoise/SVN combo, although little things like this still bite me from time to time. That said, VSS used to leave those wee *.scc files everywhere, so I assume it would have suffered the same fate from the LabVIEW installer build process.

QUOTE (Justin Goeres @ Jan 12 2009, 07:44 PM)

If I need to commit something, I commit a zip file of the installer.

I thought of that too. I mean, it's a built product, and there are methods of keeping a zip traceable, so maybe that's my answer. It's a pain to add that extra step though...

QUOTE (Justin Goeres @ Jan 12 2009, 07:44 PM)

A while back, Omar pointed me to

http://sadilek.blogspot.com/2007/07/restore-svn-in-keynotepages-documents.html'

rel='nofollow' target="_blank">a script that restores the missing .svn stuff

that has solved that problem for me. It's an OS X(/Linux/Unix) shell script, but it could be pretty easily replicated in a Windows batch file.

A custom batch file is certainly an option, but I'd need to be able to have it run automatically pre- and post-build. Anyone got any ideas on how to do that? In fact, pre- and post-build hooks would be very useful (eg: build some documentation, etc).

[Jim Kring]

QUOTE (crelf @ Jan 12 2009, 06:05 PM)

A custom batch file is certainly an option, but I'd need to be able to have it run automatically pre- and post-build. Anyone got any ideas on how to do that? In fact, pre- and post-build hooks would be very useful (eg: build some documentation, etc).

IMO, the best way to do this is to create a "Build My Project.vi" that calls "<LabVIEW>\vi.lib\AppBuilder\BuildTargetBuildSpecification.vi" to build your Project's build spec of interest. You can put whatever pre/post tasks you want in there, in addition to sequencing multiple build specs.

[crelf]

QUOTE (Jim Kring @ Jan 12 2009, 09:27 PM)

IMO, the best way to do this is to create a "Build My Project.vi" that calls "<LabVIEW>\vi.lib\AppBuilder\BuildTargetBuildSpecification.vi" to build your Project's build spec of interest. You can put whatever pre/post tasks you want in there, in addition to sequencing multiple build specs.

True - thanks for reminding me of that. That said, maintaining a custom builder for something this trivial is a pain when you work on many many projects and have more than a handful of developers. I suppose I could make it a standard operating proceedure, but I'd prefer it if the LabVIEW installer builder didn't go around deleting files it doesn't own.

Anyone from NI care to comment?

[Justin Goeres]

QUOTE (crelf @ Jan 12 2009, 07:03 PM)

maintaining a custom builder for something this trivial is a pain when you work on many many projects and have more than a handful of developers. I suppose I could make it a standard operating proceedure

It can be, but it's pretty much a write-once-per-project item (which you can make a fairly decent template for). Also, it can be part of a one-click build process that lets anybody on your team build the app (and documents the build process, assuming your code is commented).

QUOTE

but I'd prefer it if the LabVIEW installer builder didn't go around deleting files it doesn't own.

"Life is never easy for those who dream."

[jdunham]

We commit all our installers, but we don't build them with LabVIEW for various reasons we are trying to eliminate. Keeping all your successful builds is well worth the server disk space.

Why don't you just build into a parallel folder, and then when you are finished, copy the whole thing into your version-controlled folder. It's a one-line command with Windows ROBOCOPY (the replacement for the venerable XCOPY). If you are doing a manual build, you can just drag and drop one folder onto the other one and replace everything old.

Jim is right though, programmatic builds are the way to go.

Jason

[LAVA 1.0 Content]

QUOTE (mesmith @ Jan 13 2009, 12:03 AM)

I avoid this problem by not including my installers or exe's in the source code repository.

I agree, I only put source code (+docs, build files) into the SCC.

QUOTE (crelf @ Jan 13 2009, 04:03 AM)

but I'd prefer it if the LabVIEW installer builder didn't go around deleting files it doesn't own.

This is a very dangerous question, your installer folder will be filthy after a few builds, what if your code changes and you don't need a DAQmx installer to be compiled into the installer?

Especially with all the LVOOP stuff in the Executable folder you will have a lot of files that are 'changed' according to SCC but are just the result of the build.

How do you tag your code to tie it to a special build?

Maybe you should branch your code to a specific build/solution and make the executable in that location?

Ton

[Jim Kring]

QUOTE (crelf @ Jan 12 2009, 07:03 PM)

True - thanks for reminding me of that. That said, maintaining a custom builder for something this trivial is a pain when you work on many many projects and have more than a handful of developers. I suppose I could make it a standard operating proceedure, but I'd prefer it if the LabVIEW installer builder didn't go around deleting files it doesn't own.

Well, the pain that a fully automated build cures is far worse than the pain of maintaining the code. If I'm a new developer on a project and want to make a build and all I have to do is open "Build My Project.vi" and press the run button, then I can't help but not make any mistakes. And, if I want to understand how the build process works, I can always look under the hood.

As time goes by, your SOPs will become embodied in reusable code used in your build VIs -- heck, you could even package these up using VIPM, so that you don't have a custom builder for each project

[crelf]

QUOTE (jdunham @ Jan 12 2009, 11:22 PM)

Why don't you just build into a parallel folder, and then when you are finished, copy the whole thing into your version-controlled folder.

That's actually what I've ended up doing

QUOTE (Ton @ Jan 13 2009, 02:44 AM)

...your installer folder will be filthy after a few builds, what if your code changes and you don't need a DAQmx installer to be compiled into the installer?

I think changing support component requirements is a special case, and could be handled appropriately. All of the installer builds I've done have either kept the same number of installer components, or increased them - never reduced them.

QUOTE (Jim Kring @ Jan 13 2009, 08:58 AM)

...then I can't help but not make any mistakes.

What, you couldn't fit another negative in there to make it more confusing?

QUOTE (Jim Kring @ Jan 13 2009, 08:58 AM)

As time goes by, your SOPs will become embodied in reusable code used in your build VIs -- heck, you could even package these up using VIPM, so that you don't have a custom builder for each project

True - and that's what I'm thinking of doing for pre- and post-build hooks. ...but I'd still like to be able to define those in the LabVIEW builder