On Fri, 2006-12-01 at 09:51 -0600, Bob Hiestand wrote:
> > The process is running on CVS now. There are two groups of people
> > making changes to web content that rarely conflict. I want either
> > set to be able to make changes and push them to production without
> > having to coordinate, but I don't want one set's changes to accidentally
> > push committed-but-untested changes that the other set might have
> > just added. Tagging the workspace rev picks up exactly what was just
> > tested together and leaves the committed changes where they are expected
> > for the next run.
>
> I don't see an obstacle here. Tagging workspace is just as easy in
> SVN as in CVS. For now I'll assume we're talking about the setup
> where both groups are working on a shared branch, only updating
> according to whatever policies you have in place, but each free to
> commit. Tags are made from the respective workspaces.
Yes, it is a set of ongoing changes by different people. Normally
they would rarely/never touch the same files so conflicts with
specific changes aren't the issue. I just want to ensure that
(a) all the new work gets committed to the trunk so the next
update will include it, and (b) everything tagged for release
has been tested together.
> 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.
> > > If the situation truly shifts
> > > quickly from one mode to the other for you, it is still easy to start
> > > with a branch and then merge, or start a new branch when needed.
> >
> > That seems like a really inconvenient way to track what was
> > in a working copy.
>
> 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?
> > Yes, I see that this can be done. You can commit to trunk, copy
> > workspace to tag, or copy workspace to tag, then commit to trunk,
> > or maybe forget to commit to trunk but it will still be in
> > the tag. The problem isn't really functional, it is more with
> > tracking what really happened when you look at what is currently
> > on the trunk.
>
> 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.
> > 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.
> 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.
> 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.
> 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.
> > 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.
--
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 20:59:32 2006