This forum is in READ-ONLY mode.
You can look around, but if you want to ask a new question, please use the new forum.
Home » development » Miscellaneous » Use of svn whilst checking code quality - seeking advice
Use of svn whilst checking code quality - seeking advice [message #71847] Mon, 09 February 2009 11:14 Go to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
I wonder whether experienced subversion users might be able to give me some advice. I confess that I am a novice user, mainly having single-user experience with Source Safe, and I haven't waded through the substantial svn guide as I ought. I will when I have a spare week, but in the meantime I wonder whether I could get some quick advice? We use TortoiseSVN on Windows, with the svn server on Linux.

I work in a small team where several people work on our source code. Each programmer has their own branch and commits freely to that whenever they wish. We also have a trunk which I look after exclusively. However commits on other people's branches often include versions that are out-of-date from the trunk. Also, changesets are not relative to the trunk, so I might need *part* of a changeset (to add some files) and then another to make some changes. In short, our multi-user version control is in a bit of a pickle.

My policy is to try to merge other people's changes into my own branch, do some elementary tests (such as model building and a quick to ensure the changes don't cause immediate problems), then commit my own branch, and then merge into the trunk. However as above this is awkward as the changesets don't merge cleanly (I use "Merge a range of revisions" in TortoiseSVN). In theory it would be better for other developers to be able to commit to the trunk directly, so I can simply do an update and inherit their changes into my branch. However in practice we can't do this until the quality of the commits from other developers improves, and as a result I would like to remain gatekeeper.

What initial changes to our practices would folks recommend?

[Updated on: Mon, 09 February 2009 11:53]


Remember Palestine
Re: Use of svn whilst checking code quality - seeking advice [message #71911 is a reply to message #71847 ] Mon, 09 February 2009 18:08 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
As an addendum to the above, a substantial difficulty I have is examining a list of changesets from a fellow developer in order to work out what needs to be merged with my branch. On the one hand I'd like to do this to check the quality of submissions, but on the other hand I'd like to be able to take all changes and merge them into my branch.

It is not possible for me to allow colleagues to commit to trunk, because they may commit something that we can't go live with, and it then holds up the trunk until it is fixed. We often have several subsystems on the go at the same time, and when one nears completion and enters testing, it goes into the trunk. This "makes the decision" to go live with those subsystem(s) next, since they cannot be erased from the trunk.


Remember Palestine
Re: Use of svn whilst checking code quality - seeking advice [message #72546 is a reply to message #71847 ] Mon, 16 February 2009 10:59 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
Can someone give me some advice here, please?


Remember Palestine
Re: Use of svn whilst checking code quality - seeking advice [message #72552 is a reply to message #72546 ] Mon, 16 February 2009 11:28 Go to previous message
aboks  is currently offline aboks
Messages: 2
Registered: December 2008
Junior Member
I would suggest to create some 'pre-trunk'-branch, on which all developers work together and to which they all commit (instead of to their own branch). By doing this they can take changes by others into account when making their own changesets. You can then review the code from the pre-trunk-branch before merging them into the trunk.

Additionaly, I would advise you to keep some stable 'release branches' next to you trunk, as is done here at symfony. With a setup like this, only bugfixes or very minor changes may be committed to a release branch, so it maintains it's stability and you can always checkout a stable release. Active development on (potentially unstable) features is done in the trunk. Close to a new release, you can 'branch off' your trunk, stabilize it, and then release (and maintain) it as a new version.
Previous Topic:The Eternal Question: PHP Debugging in Eclipse
Next Topic:eclipse PDT Content Assist
Goto Forum:
  

powered by FUDforum - copyright ©2001-2004 FUD Forum Bulletin Board Software