General workflow for version control
The following descriptions all use TortoiseSVN and Explorer. The steps can also be done using other Subversion clients such as DelphiSvn or JCL.
The general workflow for changing code is:
- Update. Right click on your base development folder and choose TortoiseSvn -> Update.
- Resolve conflicts
- code like a demon...
- Test, test and test
- Update (again). As 1, just in case someone else has changed things
- Resolve conflicts (again)
- Add (also Delete and Ignore as required)
- Commit
- Solo developers can normally leave out steps 1,2,5,6
- Steps 7 and 8 can be combined (check the "Show unversioned files" box in the commit dialog)
- Commit. Do Adds, Deletes etc from commit dialog
Traps for young players
- Deletes and (particular) Renames should be done from within Explorer/Tortoise.
- Do commits from the base directory where possible. If you commit further down the tree, then you need to do an update before you can commit from the base.
One thing I didn't point out first time round (thanks Lars).
The golden rule of team version control:
Only check in working code to the trunk.
If you are working it a team environment, and you want to commit non working code then create a branch. That will let you have all the benefits of version control without annoying everyone you work with. Once you have completed your changes, merge your changes back into the trunk. See the manual for details.
Also, Sean's rule number 2 (for team programming):
Always update before you commit ()
If you commit without an update first, the code in the repository may not be the same as your code. That means that you don't know that the tests pass, and the code still compiles.
E.g. Bob changes the signature of DoSomething to take an extra parameter. It's in a file that you haven't touched, so there are no conflicts. All of your code uses the old signature so when you commit, it won't compile any more.
If you update first, you can catch the problem and avoid making a fool of yourself. This sort of scenario can be quite common with larger teams. Don't ask me how I know.
Manual
All Tortoise commands are available from the Explorer context menu. See here for the manual.
8 comments:
Good post! If you are in a team, and you are planning a lengthy and complex change, you might want to consider branching so that you can commit to your work-in-progress branch without having to update.
This will allow you to commit as if you were working solo with the benefit of having version control throughout your lengthy changes.
When you are good and ready to put the code as complete, you merge the branch back into the trunk.
I have been working with Perforce for a while, and one feature I miss in SVN is that in Perforce all files are read-only untill you check them out of the repository. While checking them out, you imediately start an ew changelist. Does anyone know id this is possible in SVN as well?
I'm a solo developer, still getting to grips with Subversion and TortoiseSVN. Some nice tips in there for a newbie, specifically the renaming/deleting thing.
Incidentally, I still do zips as well, but of course it's as easy as SVN using the GExperts "Backup Project" option... just a couple of clicks.
You can also just commit and do an update only if you get conflicts.
@B Jansen:
This should be possible with the "svn:needs-lock" property. If it is set you must first use the "Get Lock" menu item in the explorer to change the file from readonly to writeable.
Lars. Thanks. I have updated my post to include your quite important point.
Anon: If you are in a team, always update and run tests before you commit. I have explained further in the post.
@Andreas: But then other people cannot edit the same file at the same time, right?
I still learning Tortoise/Subversion, have had a few problems but have been able to resolve them. It would be good to see more posts about getting version control in place because not enough people take advantage of it.
Post a Comment