Michele Paterniti wrote:
> I agree with you when you say one has to reengineer his workflow in
> order to better exploit the tool he is going to use. I red quite a bit
> about how to work with Subversion, but still it is hard to me to figure
> out how we can best arrange things.
> The point is how to manage the interchange between developers and
> testers. I recall that developers and testers do not examine issues in
> the same order, and it may last some time between development and test
> of an issue, and issue time order it is not known at the beginning,
> but it may vary as things go on.
> Furthermore, it is needed to be able at any time to get from to the
> repository the collection of all the sources that passed the test
> phase.
> List but not last, thanks a lot for your kindness.
> Best regards,
> Michele Paterniti
Hello Michele,
I think the biggest benefit in your possible transition to Subversion
will be to get rid of the mindset that your project is just a sum of
individual files. Currently, your developers use the "OK" label on
individual files which pass their unit tests, and the testers check out
all the files with this label for their testing.
But, just because the project is made up of a bunch of files, each of
which is "OK", doesn't mean the project as a whole will work. That's why
Subversion doesn't really support the concept of (easily) tagging a
bunch of individual files, then checking out all those files. Most teams
tag an entire project at a particular point in time for this purpose.
A common solution to this is to assign a bunch of issues to a release.
You don't even need to know all the issues for a particular release at
the beginning, but as each issue is fixed the developer marks it "fixed
in release X". Whether you develop for release X on the trunk or in a
branch is a matter of preference, which will largely be dictated by
whether you are doing concurrent development for multiple releases at
the same time.
Depending on the size of your development and testing teams, and the
number of issues, you may need to split your release into phases, where
the developers fix a bunch of issues at first, and then the testers test
all those issues at once. If you are simply tagging individual files,
how can you know that an issue which was "fixed" at one point in time
wasn't later broken by something else? Only be dealing with the entire
project as a whole can you be sure that all files work properly together.
toby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 7 19:49:59 2007