On Fri, 2006-12-01 at 14:48 -0600, Bob Hiestand wrote:
> I misunderstood. I thought you had two distinct groups making changes
> in two areas, not individuals making changes in distinct areas. My
> comments were about having a single workspace for each of those two
> groups. I'm glad that's not what you're doing :)
The people within each group would usually be aware of what the
others were doing. The two groups mostly work separately.
> > The tracking is the part that seems to be missing, copying to
> > a tag from the working copy will accomplish the isolation from
> > concurrent updates, but now how do you make sure that what is
> > tagged is also committed on the trunk?
>
> By running commit in your working copy. I don't think any amount of
> protection gets you around this, in any source control system I've
> used. Why is this a problem?
If you "cvs add" a new file, then attempt to "cvs tag" a working copy
without committing, you'll get an error. If you have a locally modified
copy and tag without committing first the tag goes to the repository
version of that file. This is probably an error, but if you check
out the tag and test, you'll notice it and in any case what you test
is what is in the repository branch/trunk. With svn, the
tag makes an independent copy and get something that matches the
workspace but no requirement that what you just put there will be
included for ongoing work.
> > Suppose I add a file that gets included in the tag copy but forget to
> > commit to the trunk since they are now unrelated steps. How do I
> > figure out what happened without visiting every tag? With CVS, the
> > tag is embedded in the file so you can't have one without the other.
>
> ... vs the problem in CVS where you tag your uncommitted working copy
> and DON'T actually tag what you think you have. I don't see an issue
> in either case. Both systems only work if you commit.
With cvs, the QA guys can catch it because the tag they check out
will have the same problem as the repository. With svn the tag
will match the workspace and everything looks dandy. Then the
next guy to update/commit/tag will be missing that change. If you
can find the tag that has what you are missing, I suppose you
can merge it back, but what tracks things that direction?
> Quite true. This may be a feature or not, depending on the beholder.
> Isn't your request that you be sure that a tag mirrors your WC? SVN
> does that, CVS does not.
I agree it could be a feature. But my other request was to make sure
that the repository branch/trunk also accumulates all changes.
> Generally speaking, tracking back is harder in SVN, but only mildly
> so. Both CVS and SVN require good process if you're in a heavily
> branched environment. SVN has the advantage that you can use metadata
> directly to assist in this. If you set up your merge tool to stamp a
> particular revision as a change from another branch, you (or another
> tool) can automatically follow that change to the appropriate branch.
Something that made sure there was a match for the rev number that
svn info shows on the trunk for every file in the tag would work.
> Here, though, it seems we're drifting into theory instead of
> supporting your specific needs. While I'm happy to do both, I don't
> want to confuse myself any more than necessary. So, back to tagging
> WC: as far as SVN being harder to track, the fact that you can
> provide log messages and metadata to copies of the WC (instead of just
> moving a tag in a file) provides actual history and tracking. CVS
> lacks this entirely. CVS lets you see in one long (somewhat hard to
> read, judging from the failure of many developers in doing so) log
> stream all the changes to the file. This is incredibly nice.
I've always liked the cvsweb view of this..
> In
> practice, however, seeing that a change was made on another branch and
> running log against the repository for that branch is not really a big
> deal, at least to me.
If a change exists only in a specific tag but you don't know which
one, how do you find it?
> > I think what I really want is a merge back from the tag into the trunk
> > to get a log message relating the tag to the trunk, but that doesn't
> > seem easy and if you remembered to commit all your changes, shouldn't
> > actually do anything.
>
> I don't think you should ever have to merge from your tags to the
> trunk, given the prior discussion. You just commit from your
> workspace.
Agreed, that's the correct action, but much of the point of revision
control is to be able to fix mistakes. So this is the theoretical
side: Your QA testing passes on a tag containing something that
wasn't committed to the trunk. At some future point perhaps many
tags later you again test the functionality that change would have
affected and find that the trunk doesn't have what you tested back
then. How do you know where to find the now-unknown missing pieces?
> If you really wanted to, however, you could automate it even without
> using the RELEASE-n tags you have to use in CVS. I'm not in a
> convenient place to whip up the code to do so, but I'd think you could
> pull such information pretty easily through the log interface (knowing
> that you'd probably have to jump with peg revisions).
I think I'm missing a concept of how disjoint tags can be tracked
through the log. I didn't think they were required to have anything
in common with anything else. But, I didn't realize that deleting
and recreating one with the same name created a versioned copy
either.
--
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 Fri Dec 1 23:18:25 2006