On 12/1/06, Les Mikesell <lesmikesell@gmail.com> wrote:
> > SVN vs CVS
> > here doesn't make a difference. Neither allows each group to have
> > multiple copies of their workspaces without branching, however, so I
> > assume that there is one (shared) working copy per group?
>
> Not sure what you mean here. Both svn and cvs allow any number
> of working copies to be checked out, and letting them work
> concurrently is the point of this exercise. Normally someone
> making a change would update to the current repository contents,
> edit something and commit, do some testing or tag it for some QA
> before release, but the tag is to identify exactly the set of files
> present when this change was made. If someone else happens to
> commit a change towards future releases between this copy's update and
> commit, I don't want it included in this tag but if it was there
> first and passes the testing it can be.
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 :)
> > I am not referring to tracking what's in a working copy, that is
> > already covered. I'm referring here to selective sharing of code
> > (which sounds like it's simpler in your process than I feared).
>
> 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?
> > I don't see why that is. Since we're talking about a single branch,
> > the trunk, it contains all history. Do you mean it's hard to see when
> > tags were made? What information do you feel is missing in SVN tags
> > for this situation?
>
> 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.
> > > Tags are sort of an end-point in subversion instead of a name for
> > > a checkpoint version in your ongoing work.
> >
> > Tags in subversion work exactly the same in that respect as in CVS.
> > What specific functionality of tags do you see in CVS but not in SVN?
>
> You can have something in a tag that isn't anywhere else.
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.
> > That's exactly how it works in SVN. If you tag from a workspace, you
> > have a copy of each file at that point, regardless of the state of an
> > overall SVN repository revision. What feature of CVS do you feel does
> > this better?
>
> In CVS, tags can only refer to file revisions that appear in the
> relevant branch/trunk. In SVN, the tag is fully equivalent to
> a branch/trunk itself and permits things to be included that
> don't exist anywhere else. By itself that's not a bad thing but
> it doesn't mesh well with thinking of the tags as snapshots of the
> ongoing work which you expect to be on the trunk or branches and
> I don't see a handy way to track back any differences.
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.
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. 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.
> > At this point, it sounds like branches aren't needed for your workflow
> > at all. I don't want to mix the discussion more than I inadvertently
> > did with respect to branching vs the shared branch, tagged WC models.
>
> If conflicts were likely, I'd agree that branches for each change would
> be worthwhile. Most of the time only the individual changes are updated
> into production anyway, but I want the scheme to be safe for full
> updates
> without dragging in anything unexpected.
It seems to me that your workflow doesn't really change from CVS to
SVN for this particular development model.
> > In any event, just like in CVS, you have to manually manage your
> > merges (but this apparently scares people more than it should, as it's
> > an easy process in both systems).
>
> 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.
> > > In the CVS scheme I would float the existing RELEASE-1 tag
> > > to the current RELEASE (etc.) in the repository,
>
> > Actually, this is a strong advantage to SVN. I don't know what you
> > mean by "That's not hte way I'd want to reuse them." The scheme you
> > describe works fine in SVN, except instead of using the Force
> > parameter to tag, you delete the tag first, then create it again. The
> > content, if only existing on that tag (never committed on trunk) does
> > NOT go away in SVN. You can always retrieve it, even from a deleted
> > tag specifically because tags are directories, which are versioned.
> > In SVN, therefore, you can always ask the question, what did RELEASE
> > look like 3 weeks ago? In CVS it's impossible, because it does not
> > version tags.
>
> The question I'd want to ask is what was it before the current one, or
> the one before that? Is there a way to refer to those points with
> known names in a script? That's the reason for floating tags to them
> in the CVS repository.
You can do the same thing you're currently doing with your RELEASE and
RELEASE-n tags. Again, it's two commands instead of one (but the
bonus is that they execute MUCH more quickly). I don't think anything
changes for you, functionally.
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).
Thanks,
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 1 21:49:36 2006