On Sat, 2006-11-18 at 02:00, Alan Barrett wrote:
> > > Fair point. But I'd still prefer to do the testing with a
> > > non-mixed-revision WC, and do an URL to URL copy.
> >
> > Why? I'd much rather have, for example, a release tag applied
> > to the actual contents of a QA working/tested copy than
> > whatever happens to have subsequently been dumped on the
> > trunk.
>
> 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.
> You seem to have the idea that I was advocating making tags from things
> that had not been tested. I have no idea where you got that idea. I
> advocate making tags from things that have been tested and that also
> share the same revision number.
But that might be impossible. What if other changes are happening
faster than you can test?
> > What's the point of a tag being a fully-functional copy in its own
> > right if you insist on it being a duplicate of some other revision
> > state?
>
> Simply that it makes the history easier to follow. I don't want
> somebody in the future to waste time wondering why a tag was made from
> mixed revisions instead of a single revision.
The reason would always be clear to me, since my intent with
a tag is to note the state of my workspace. I suppose you
could branch to have a second place to copy a change made
before the tag, but that makes it even harder to follow
the history when you want the change to appear back in
the trunk and doesn't really have any use of its own.
> If there really is a good reason for the tag to be made from mixed
> revisions, I think that it should be clearly documented in the commit
> log.
The point is that you shouldn't be concerned about trunk
changes that happen after you get to a point where you are
thinking about tagging. Other people making other changes
toward the next version should be a normal thing. I always
worked that way in CVS with no expectations about the
current state of HEAD and always tagging from a workspace
state. I don't see how subversion would change this expectation
in a multiuser environment since its atomic actions are still
just per-user-action. I suppose you could make a branch per user
to maintain a known state or always verify that the revision
numbers from your update/commit/tag are sequential, but I
don't see the point.
Maybe I'm missing some magic attribute of the subversion
revision numbers because CVS didn't have them. Suppose you
have a workspace checked out, changes and testing completed,
and are ready to commit and tag, but the trunk currently has
changes you don't want to incorporate. How would you handle
that, and what subsequent operations would be different
compared to just committing to the trunk with appropriate
messages then tagging from the workspace? You may end up
with trunk/HEAD in an unknown state, but that seems normal
to me for development.
> > And in any case, if you want to insist on the WC not being
> > mixed-rev at the time you tag, you have the option to commit
> > and update before tagging, then still tag from the WC. At
> > least you can then claim to know something about what you
> > just tagged.
>
> Yes, that's another way of achieving the same result.
But perhaps not desirable - you may not want those other
changes. You could branch for your changes, but unless
I'm missing the handy way to track this, it becomes harder
to follow the history than committing to the trunk in
the first place.
--
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 19:19:11 2006