Subversion and mixed-revisions: recipe for broken builds?

Question

Hello all

I'm just comming back to subversion after using TFS for some time and generaly i'm quite exited :)

There is one thing i remember differently. I don't remember beeing able to commit from an out of date working copy. Or maybe my memory just fails me on the definition of "out of date". I thought "out of date" meant that any file had been touched since i last updated my working copy, and not just that a file I touched locally had been touched (what i would call a conflict).

The reason why I see this as a problem is that it makes it very easy to "break the build" if I can commit my changes without first integrating with the changes made by others.

So was this mixed-revisions thing added resently or is it just me?

Answer 1

Short answer: In general, it's a good practice to make builds that are meant to leave the developer's desks from a freshly checked-out tag. If possible, on a separate machine.

If you follow that rule, you can sleep better.

Somewhat longer answer: That means, before making a release you have to update your working copy, build it, run all the tests, and when your satisfied, make a copy (a tag) from it. Then instruct the build machine to make a build from a fresh checkout of this tag. The result of the build you hand over to the test department.

If you later need to retrieve a specific version, you always have that tag to check out. If that version is tagged "tags/release_4.2.0" and you need to make a fix, copy the tag to some branch ("branches/release_4.2.1") and fix it there. When you're sure it works as expected, then move the branch to "tags/release_4.2.1". Again, have the build machine checkout that tag, build the code, and hand that over to testing.

Answer 2

The ability to commmit to such a "mixed" revision doesn't strike me as being inherently unsafe. Even if you're using a VCS that requires all files to be completely up to date before doing a commit, the VCS isn't going to be able to verify that you actually compiled the code or ran all the unit tests. That sort of thing should be covered by developer disciple and a continuous integration system.

Subversion has a very file-centric view of the world, much like its CVS ancestor. You can check out a specific revision of a specific file without touching any of the files around it. This is in contrast to other systems such as Git (I'm unfamiliar with the specifics of TFS) where the specific checked-out revisions of individual files are not tracked. Instead, the whole checkout is a view of the repository at a specific point in its history, and any deviations from that are considered new changes. Of course, you are still free to commit as much or as little of those new changes as you like, with the possibility of breaking the build if you don't choose the correct combination.

Answer 3

It's you, since it has always been like this ;-)

Your commit will fail if any of the items you're trying to commit is out-of-date, and the repository has one 'general' revision number, but as long as everything you're about to commit is up-to-date, you CAN commit. That does not mean it's a best practice of course.

Remember that svn is not only used in software development. In general this ability is probably nice to have.

And furthermore, AFAIK TFS works very similar in this regard, right?

Answer 4

No, you can't commit svn out-of-date files. Read this: http://subversion.tigris.org/faq.html#wc-out-of-date

Answer 5

Thanks for clearing that up guys. Thinking about it, I guess what I suggested would be implemented client side anyways.. and i totally get that it would still be up to developers to ensure that everything compiles. In reality this has not been a huge issue, but there have been several times where a developer have commited work without first updating he's working copy resulting in a broken head revision.

On a side note, how about this example from Tortoise: http://tortoisesvn.net/node/13

"Now if you modify File2 and try to commit, it fails. The client tells the repository that File2 is at revision 2 with local modifications, but the repository is already at revision 3. If you then do an update, File2 will be at revision 3 as well (and of course your local changes will still be there)."

I don't actually get the "out of date" message, but you should think that this would have been the case at some point?