SVN history as useful programmer's tool
Author
I'm sure everyone who ever used it knows, or at least I did as I first encountered it: The history of source code files in a revision system contains very useful information.
By diffing the current version with a version from the past, or diffing two versions of the past (with TortoiseSVN in my case), you can see what changes were made between this and that date.
This allows to see things like:
-why was something added or changed?
-who did it?
-why did he do it?
-how did this code, class or framework evolve to its current state?
Especially if the SVN comment field is filled in with numbers of bugs in the bug database (like we do) this can be even handier.
This information allows to develop more efficiently, and not repeat mistakes of the past.
Also, if someone who used to write the code left the company, the SVN history can be the only thing left that documents his code.
This is all very useful, but I read a lot of programming books, and they talk about extreme programming, design patterns, iterative development processes, and so on, but I never saw one talk about how the history of a revision system helps in a collaborative development process. Did any author ever acknowledge this?
I can't say I've read any author's testimonials, but I can give my personal recommendation for the use of SVN and its trickery as a programming aide.
I regularly have a quick look at previous code to see why I changed things, and on limited occasions it lead me to revert to the old version after some comparison.
One of the best uses I get from the SVN is the comments box, coupled with individual usernames/passwords. I make it a firm rule that EVERY commit must be commented, which really makes a difference: I know who did what, when and why. The comments box also doubles as a diary - I commit every night with a comment of what I did that day, which is a requirement for my final year University project.
I regularly have a quick look at previous code to see why I changed things, and on limited occasions it lead me to revert to the old version after some comparison.
One of the best uses I get from the SVN is the comments box, coupled with individual usernames/passwords. I make it a firm rule that EVERY commit must be commented, which really makes a difference: I know who did what, when and why. The comments box also doubles as a diary - I commit every night with a comment of what I did that day, which is a requirement for my final year University project.
Another benefit of having source control is that it allows the programmer to make wild changes to code, either to just try something or as a major system overhaul - knowing that if something goes wrong beyond repair, all that is lost is time on the programmer's part. The source code effectively remains backed up.
Without such a "living" backup programmers tend to either make copious (and confusing) backups of code before embarking of scary changes, or forget and start going down the road-of-no-return. Source Control gives you the opportunity to scrap it and start over.
But, in all fairness, so does any good backup system.
Without such a "living" backup programmers tend to either make copious (and confusing) backups of code before embarking of scary changes, or forget and start going down the road-of-no-return. Source Control gives you the opportunity to scrap it and start over.
But, in all fairness, so does any good backup system.
Where I work, we bridged SVN with our bug-tracking software. Commits that include an bug id have their changed files sent over to the bug-tracking software. So for each bug-fix we can see which files were touched.
No one else has mentioned it, but if your project has an automated test suite, your code repository can be used with regression analysis to pinpoint which commits breaks existing functionality.
No one else has mentioned it, but if your project has an automated test suite, your code repository can be used with regression analysis to pinpoint which commits breaks existing functionality.
I think the most useful use of SVN for me is the "check for modifications" option just before you commit something. You can review everything you did if you forgot something that was just a test before sending crap on the server.
Quote:Original post by Dunge
I think the most useful use of SVN for me is the "check for modifications" option just before you commit something. You can review everything you did if you forgot something that was just a test before sending crap on the server.
Interesting, what software are you using? I couldn't find that option in Tortoise (Windows XP) or Konqueror (KDE 4.1), that's something I'd find pretty useful.
Also, for those of you using Tortoise SVN, the "Blame" command has been one of my favorite so far.
It can be used on any file actually in the repository and will tell you on what revision every single line was last changed in the repository. It can be useful to track down who worked on certain part of the code so you can ask question to specific programmers rather then spamming the entire department and since revisions are dated you can see if the file has been changed recently and to what extent.
It can be used on any file actually in the repository and will tell you on what revision every single line was last changed in the repository. It can be useful to track down who worked on certain part of the code so you can ask question to specific programmers rather then spamming the entire department and since revisions are dated you can see if the file has been changed recently and to what extent.
Quote:Original post by Lode
I'm sure everyone who ever used it knows, or at least I did as I first encountered it: The history of source code files in a revision system contains very useful information.
By diffing the current version with a version from the past, or diffing two versions of the past (with TortoiseSVN in my case), you can see what changes were made between this and that date.
This allows to see things like:
-why was something added or changed?
-who did it?
-why did he do it?
-how did this code, class or framework evolve to its current state?
Especially if the SVN comment field is filled in with numbers of bugs in the bug database (like we do) this can be even handier.
This information allows to develop more efficiently, and not repeat mistakes of the past.
Also, if someone who used to write the code left the company, the SVN history can be the only thing left that documents his code.
This is all very useful, but I read a lot of programming books, and they talk about extreme programming, design patterns, iterative development processes, and so on, but I never saw one talk about how the history of a revision system helps in a collaborative development process. Did any author ever acknowledge this?
Oh how I miss svn, I'm stuck with using sourcesafe in my current job, and it has to be the single most depressing part of my day. I found this rather amusing and enlightening critique of sourcesafe.
At my previous job we used custom tags in svn commits and then generated the release logs using a script, which was a great way of ensuring that every change in a release was documented for the user.
Quote:Original post by deadstarQuote:Original post by Dunge
I think the most useful use of SVN for me is the "check for modifications" option just before you commit something. You can review everything you did if you forgot something that was just a test before sending crap on the server.
Interesting, what software are you using? I couldn't find that option in Tortoise (Windows XP) or Konqueror (KDE 4.1), that's something I'd find pretty useful.
It's in Tortoise, 3rd menu item from the top for me.
I like SVN. I like that they added merge tracking in 1.5, because it gave me fits in 1.4.x. I don't like that svndumpfilter exclude can not exclude a node if it was copied from. I don't like that you can not set server-side policies and instead have to rely on hooks, which can prove extremely unwieldy (I once wrote a hook in C# as a pair of applications that could potentially be in a deadlock/race condition, because it was supposed to filter the items in a transaction and apply svn:needs-lock to files that can't be diffed and merged - images, PDFs, DOCs, etc).
The hardest part of using SVN in an organization is introducing it, getting people to use it. You start writing hooks to apply heuristics and reject commits without appropriate comments, for instance, because people check in changes without comments otherwise (which renders all the usefulness Lode mentions moot).
SVN is one tool I actually seriously consider getting involved with, per open source. Server-side policies and better, deeper repository administration tools are my wish items (you can tell I administered the repo, can't you? [smile]).
The hardest part of using SVN in an organization is introducing it, getting people to use it. You start writing hooks to apply heuristics and reject commits without appropriate comments, for instance, because people check in changes without comments otherwise (which renders all the usefulness Lode mentions moot).
SVN is one tool I actually seriously consider getting involved with, per open source. Server-side policies and better, deeper repository administration tools are my wish items (you can tell I administered the repo, can't you? [smile]).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
