On Thu, 2006-11-30 at 11:07 -0600, Bob Hiestand wrote:
> On 11/29/06, Les Mikesell <lesmikesell@gmail.com> wrote:
> > The problem comes when you want both a frozen snapshot of your workspace
> > _and_ your changes committed to the head of a trunk/branch where others
> > may be working. There is nothing to tie these together. When you look
> > at the trunk version you can't see anything to show when the tag copy
> > was made. When you look at the tag, you might find something that isn't
> > even committed to the trunk since nothing forces you to commit there as
> > well.
>
> Are you describing your actual development process? You are making
> changes that others will see while you don't see any of their changes?
> That seems to be an extreme example, and not a normal work flow.
It isn't that I don't want their changes - I just don't want them
tagged to go into production until they've been tested together
with all the others.
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.
> > How do you pick up other people's changes when you want them?
>
> You can merge other people's changes to your branch(es) if it's
> important. Again, however, it sounds like your development process is
> askew if you need such rapid sharing of code: either you need rapid
> sharing of changes or you don't.
I do need rapid sharing of code - just not in the middle of testing
a set that was just added and deploying it.
> 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.
> 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.
> > 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.
> > 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.
> >
> > 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.
> (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?
> (b) I would use revision properties to indicate merges.
>
> > And the other missing piece is the ability to float a tag from
> > one place to another so you can reuse known names. I think someone
> > mentioned a utility that might do this, so perhaps the underlying
> > mechanism is available.
>
> 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.
--
Les Mikesell
lesmiksell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 30 22:43:33 2006