On 11/30/06, Les Mikesell <lesmikesell@gmail.com> 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. 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?
> > 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).
> > Again, while this doesn't sound like an ideal workflow, it is
> > supported by the tool already. Use a shared directory (for now,
> > calling it "trunk"). You make the changes in your working copy. When
> > you are satisfied with them, you create a release tag. You then
> > commit your changes. No branching, no merging (except standard
> > conflict resolution).
>
> 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?
> > > The subversion manual shows an understanding that workspaces often need
> > > to hold mixed revisions. For the same reasons, you will often need
> > > to be able to reproduce that workspace and the only mechanism that
> > > subversion provides is a copy to a new tag or branch, neither of
> > > which meshes well with ongoing concurrent work. If someone else has
> > > committed changes you don't want to include at the time you commit,
> > > you cannot make a trunk or existing branch revision match what you
> > > have in your working copy.
> >
> > I don't understand this comment. Why does using tags to reproduce a
> > workspace not mesh with ongoing concurrent work? Since you tagged
> > from your workspace, someone committing elsewhere has no impact on
> > this.
>
> 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?
> > > If you have committed all your changes, everything is in fact in the
> > > repository, but no "repository revision" matches the state you want
> > > if unwanted commits happened first.
> >
> > It seems to me you are describing a purely hypothetical development
> > environment with unrealistic opposing requirements.
>
> I think it _can_ happen in anyone's development environment if you
> haven't pre-arranged times that someone is allowed to commit. It
> may not be common that someone does commit a change you want in
> the next rev before you commit the last one you want for this
> round, but I think the mechanism should have a way to prevent this
> accident from being included without forcing you to isolate everything
> in a branch.
But tagging your workspace does this, whether in CVS or SVN.
> > > Copying workspace to tag is OK, but now how do you (a) know that
> > > everything in the tag really was committed to the trunk and (b)
> > > if it was, find out when by looking at the copy in the trunk?
> >
> > While merge tracking is an obvious weakness of SVN, I do not see how
> > labels change the situation.
>
> That would depend on how they were implemented, of course. If the
> labels refer to file revisions at the state you want (even though
> no repository revision may contain exactly that set), then they
> have to exist in the ongoing part of the repository and will have
> their complete commit history.
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?
> > (a) See my above statement about using more branches if you have
> > individual functional changes. If you always merge the entire branch,
> > there is not confusion over what exactly you merged.
>
> How do you tell after the fact that that was done, though (i.e. that
> a merge from the branch put something exactly matching the tag onto
> the trunk)? Hmmm, what kind of tracking would you get if you
> always copied the workspace to a tag, then merged the tag to the
> trunk? Would that always have a null effect if you had already
> committed any changes to the trunk? And could you tell from the
> trunk when and if it had been done?
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.
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).
> > Tag names are easily reusable. Just delete the original tag and recreate it.
>
> That's not the way I'd want to reuse them. In the CVS scheme I would
> float
> the existing RELEASE-1 tag to the current RELEASE (etc.) in the
> repository,
> then tag the new RELEASE from the workspace, so that some canned scripts
> would be able to find the right things. I don't want the content that
> was tagged to go away, though. If some file revision xxx only existed
> in the tag as a result of copying from the workspace and forgetting to
> commit elsewhere, won't that be gone if you delete the tag? In CVS all
> the file revision number history remains fixed regardless of what you
> do with any tags that might have referred to them.
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.
Thank you,
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 16:51:56 2006