Michele Paterniti wrote:
> I am currently using Visual SourceSafe and I am thinking about moving to
> Subversion, but it is hard for me to find a Subversion usage model
> that fits my
> developing team needs (and habits).
> I will shortly describe our current SCM usage model.
> The code is managed in a unique repository, with no branches at all.
> A VSS label, namely 'OK', is used to track the current candidate
> release, i.e.
> the label marks all the most recent file revisions that successuffly
> passed the
> test and thus that are going to take part in the next production release.
> At any point of time, one can obtain from the SCM two things:
> 1. the set of all successfully tested file versions (by using a
> VSS get with
> label), that allow a consistent build to release a new version
> of the product;
> 2. last file versions, that are used for test release build.
> Let's see how it works from a developer perspective.
> When a developer start a task (Task 1 say) (usually lasting for a
> short time,
> not more than two weeks), he loks exclusively the files he needs. When
> it's
> ready for test, he commits its changes to the SCM repository, keeping the
> exclusive lock. Then he can update the testing environment, by
> building a test
> release with all last file version, freshly got from the SCM
> repository. Then
> he would probably start a new task.
> In the meanwhile other developers are working in the same way,
> locking the
> needed files and updating the repository.
> If the test shows something has gone wrong for Task 1, the developer
> will
> update the repository with the newly amended files, maybe even locking
> and
> updating some other files, if neeeded.
> When eventually the test is passed, the developer releases the locks and
> contextually marks all the last versions of involved file with the
> label 'OK'.
> This process has many limitations but, since the group is small and the
> workflow is quite fluid, everything works fine. Even exclusive locks
> are not
> an issue.
> Note that the VSS labelling system allows to label individual file
> versions,
> thus it has a finer granularity than Subversion tagging (or branching, as
> you please), which applies to whole revisions.
> I will be grateful to anyone who can suggest a way to migrate our
> working
> process to Subversion.
> Tanks in advance,
> Michele Paterniti
This doesn't sound like a workflow which can be directly mapped to
Subversion. However, I see several problems with the workflow; the
biggest one being that a collection of "OK" files doesn't necessarily
make an OK product. I'm guessing that you also do integration testing on
the full product (composed of "OK" files) before shipping it, but how
can you be sure that in the meantime no one has applied the "OK" label
to a different file, which by itself is OK, but breaks something else?
You may want to take a look at the "best practices" document, which
defines 3 common branching scenarios that Subversion users use:
http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html
The "Branch-When-Needed" system works well for most Subversion users. In
this scenario, you require that code on the trunk always compiles and
passes regression tests. So in a sense, the trunk becomes your "OK"
files. Then, when you are getting close to a release, you can create a
branch for that release to do full integration testing and work out any
bugs. Development for the next release can continue on the trunk, while
the release branch is stabilized. Once the release is shipped, tag it,
merge its branch back to trunk, then delete it (the tag will allow you
to get back that release's exact contents later if necessary).
One of the biggest mistakes that former VSS users make when they switch
to Subversion is trying to mirror their previous workflow habits
*exactly* in Subversion. This often leads to failure because the
methodologies of the two systems are very different. So instead, I'd
recommend taking a step back and figuring out exactly what you need your
SCM system to accomplish, and how to implement those goals in
Subversion, rather than looking at it from the standpoint of "how do I
simulate VSS labels in Subversion".
toby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 1 22:27:35 2007