Subversion: add file but don't version it?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This might be a case of RTFM, but then I just don't see it: I was wondering if it is possible to have files added to a repository but at the same time keep them unversioned?

Currently I'm thinking of the .APS and .AWS files that AVR Studio creates. Especially the .AWS file gets modified whenever the project is opened in AVR Studio resulting in Subversion (and TortoiseSVN respectively, which is what I'm using as a frontend) to mark the checked out folder as modified. Adding the files to the ignore list keeps the files from being added to the repository at all, so when checking out into a new folder the AVR Studio project and workspace files are missing.

The second question would be: Which files do you have on the ignore list? Ignoring the .HEX and .EEP files as well as the .O and .D files seem natural since they are created at compile time. Any other ones?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are missing the first principle of Subversion. It is not individual files that are versioned. It is the complete repository tree. Every time anything is commited to the repository a new revision of the complete file tree is created.

(Aside: According to the Subversion documentation this is not as costly as you might think. The underlying filesystem (eg. FSFS) handles the actual copying (or not) depending on the situation. I recall reading the phrase "cheap copies" or somesuch, but can't find it in the documentatin right now. For an altered binary file I suppose you still have to pay for the copy. For those it might make sense to have an option "Store only latest version".)

I had a look in the properties section of the documentation but there was nothing usable as far as I could see.

Well, I actually stumbled over the svn:needs-lock property. This makes the file read-only upon check-out. The next step was to see how gracefully Studio handles a r/o file. Not so good, it turns out. If you actually change the project, eg. adding a file, and do "Save all" then you get an error in the Message window (I would have preferred a message box). Worse: If you add a file to the project and then try to exit studio you get a question if you want to save. You answer "Yes" and then Studio exits although it fails to save. I hope you see what confusion this might lead to...

I'm on vacation but if I cn get in touch with the Subversion gurus at work I'll ask them about your problem.

Maybe we should send a bug report to Atmel on the Studio behavior?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
You are missing the first principle of Subversion. It is not individual files that are versioned. It is the complete repository tree. Every time anything is commited to the repository a new revision of the complete file tree is created.

(Aside: According to the Subversion documentation this is not as costly as you might think. The underlying filesystem (eg. FSFS) handles the actual copying (or not) depending on the situation. I recall reading the phrase "cheap copies" or somesuch, but can't find it in the documentatin right now. For an altered binary file I suppose you still have to pay for the copy. For those it might make sense to have an option "Store only latest version".)


Thanks, Johan.

I wasn´t thinking about the 'costs' of a copy or climbing revision numbers. My wish would be to have files that are which are necessary for the project in the repository (so I don't have to worry about them being there if I check out a project to a new directory, like the AVR Studio project file) but aren't under version control because it's not necessary to keep track of their changes.

Quote:
I had a look in the properties section of the documentation but there was nothing usable as far as I could see.

Well, I actually stumbled over the svn:needs-lock property. This makes the file read-only upon check-out. The next step was to see how gracefully Studio handles a r/o file. Not so good, it turns out. If you actually change the project, eg. adding a file, and do "Save all" then you get an error in the Message window (I would have preferred a message box). Worse: If you add a file to the project and then try to exit studio you get a question if you want to save. You answer "Yes" and then Studio exits although it fails to save. I hope you see what confusion this might lead to...
[...]
Maybe we should send a bug report to Atmel on the Studio behavior?


Well, this is not decent behaviour. But if they pointed stderr to the message window, it's no wonder the message pops up there. But in cases like this with the possibility of losing hours of work, a more prominent warning would be appropriate. To avoid filing the bug twice: Are you going to do it or shall I do it?
Quote:
I'm on vacation but if I cn get in touch with the Subversion gurus at work I'll ask them about your problem.

No hurry, calling or mailing the office is always a bad idea when you're on holidays. :wink: There's always that one task or question that only you can solve: "Ah, while I've got you on the phone, Mr. Foo called and he has a problem. I know you're on holidays, but do you have a minute to spare?" :shock:

angenäm ferie

Ingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ikletti wrote:
but aren't under version control because it's not necessary to keep track of their changes.

I simpply don't understand that comment. Say that half way through the project you determined that you got the most efficient code size/speed by switching from -Os to -O3 or something. That's a setting in the .aps file. I'd suggest you want that revision to be logged just as much as any revision to any line of C or Asm

While I use VSS and the projects we work on are for different chips and different build systems the bottom line is that whether it be a Win32 C program or a MIPS4000 or an ARM9 project or whatever we version control all the build/make/project files just as much as everything else in the project and, in fact, once the project reaches the support phase I'd suggest it's the make/build files that get changed almost more than any other file in the tree.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
ikletti wrote:
but aren't under version control because it's not necessary to keep track of their changes.

I simpply don't understand that comment. Say that half way through the project you determined that you got the most efficient code size/speed by switching from -Os to -O3 or something. That's a setting in the .aps file. I'd suggest you want that revision to be logged just as much as any revision to any line of C or Asm

Good and true point, Cliff. I'd almost have outsmarted myself: The makefile is well under version control, so everything should be fine. What I did not take into account is the fact that, as you said, the compiler options are defined in AVR Studio's .APS file, as well. So changing the options without actually compiling will result in differences between the studio project file and the makefile.

Since this were 'experimental' thoughts, no harm has been done yet :)

Thanks,

Ingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IMO the principal problem lies in this Studio mal-design (rather than in Subversion):

Quote:
.AWS file gets modified whenever the project is opened in AVR Studio

Ingo! I'll file/send a bug report on the "save to write-protedted project file" issue.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ikletti wrote:
The second question would be: Which files do you have on the ignore list? Ignoring the .HEX and .EEP files as well as the .O and .D files seem natural since they are created at compile time. Any other ones?
I ignore the entire default directory since those files are created by compilation. I also ignore files generated by my editor (emacs): TAGS and dep. Currently, I'm ignoring the .aws file since the best I can tell it only stores editor window files and positions. But, it would take very little to me to decide to put that file in the repository as well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Personally I'd version control the final output files too - though not the intermediary build files. This way when someone asks "how did this work in V36 last May" you can simply pull out the prebuilt .elf or .hex and plug it into a device and check without having to pull the whole build tree and rebuild everything.

(this becomes more of an issue on projects with more than 1,000 source files, generating megabytes of code and taking 20-30 minutes to build the entire tree!)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, that makes excellent sense in that context.