On Sat, 2006-11-18 at 13:31, Alan Barrett wrote:
> > > Me too. Checking out a specific revision (or updating to a specific
> > > revision), testing it, and then copying it, will give you that, while
> > > also avoiding a mixed-revision copy.
> >
> > That only works if you make no changes and tag the revision
> > number from your checkout or last update - or you are lucky...
> > If you make a change and commit it back, someone else may
> > have made other changes already.
>
> Your workflow is clearly different from mine. If my role is testing and
> tagging, then I will not be making changes and committing them; I'll be
> checking out a specified revision (probably from a stable branch with a
> low commit rate), testing it, and tagging it if it's good; perhaps I'll
> also update a version number and commit that. If my role is developing
> the trunk, I won't be tagging. If my role is updating a stable branch,
> I'll be aware when tagging is imminent, and try not to break it.
Yes, I'd expect the person making a candidate for testing to
apply the tag after making the last change, and the tester
to check out the tag. The workflow beyond that point might
vary depending on the product if the test fails, but if
everything checks out the tag would then be used to build
the production version. That always worked with CVS but
there weren't many other choices.
> If, in my testing role, I find that I am forced to use mixed revisions,
> I'll make that clear in the log message when the tag is committed, but
> I'd expect that to be rare (apart from updating a version number).
The person making the last change - where I want the tag applied -
may have a mixed revision in his workspace if subsequent changes
that he doesn't want at this tag point have happened at the
head where he is working by the time he needs to commit his
changes. To force everything to stay in sync without mixed
revisions, you'd have to branch just to hold this state, then
tag a state of the branch. I'm missing the value of this extra
step, since the branch and tag are fully equivalent.
If it turns out that you need additional changes here that you
don't want back on the development head you can copy a branch
from the tag. Or, depending on the nature of the changes needed
you may bail on this tag and start over with an update from
the development head.
What's the advantage of the tester pulling a branch revision
number instead of a tag?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 18 21:43:17 2006