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.
> Exactly, and what I'm thinking about is that I don't want to force
> everyone else to stop working or to be unable to update to each
> other's changes easily just because I need to make a few changes
> to an otherwise frozen snapshot.
This is what (cheap) copies-as-branches facilitates. If you are
worried about making distinct changes to your working environment
(branch), just create multiple branches. When you want to merge a
particular logical change, you can merge the entire branch and not
worry about other changes you're making concurrently.
> > In the end this is
> > what you really care about. For example, I have my own individual area in
> > the repository. I create a branch when I start working on something (other
> > than truly trivial changes.) I make changes and check stuff in very
> > frequently.
>
> 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. 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.
> > If I screw something up I can go back easily. I don't have to
> > keep a bunch of copies of files with intermediate changes in them. Then once
> > I have completed my work I merge it into the main development tree wherever
> > it belongs.
>
> Suppose you also have to roll out a release of what you have while
> others are making changes that will go in the next release, and it's on
> a fast schedule - you might be doing it again tomorrow. You want to
> tag every release so you can easily back out to an earlier one and
> you want the changes you make to be included when you pick up the
> concurrent work on the trunk for the next round. Is it worth all the
> branching and merging just to identify the mixed revision in your
> working copy now?
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).
> 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.
> > If a different mechanism is going to be added,
> > >> it should be something that can handle these needed
> > >> mixed-revision states.
> >
> > No matter what that mechanism is, it will require making a copy of your
> > mixed revision. If a copy is not made then there isn't anything to 'tag.'
>
> 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. If you want an
isolated environment use a branch. If not, develop on the same
branch/trunk as others. If you need mostly shared development with
occasional control, tag from your workspace and update as needed.
> > Subversion currently let you decide where that copy will be created by
> > leaving it up to you to make it.
>
> 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.
(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.
(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.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 30 18:08:06 2006