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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 27 21:40:23 2007