On Sun, Mar 21, 2004 at 12:39:17AM +0200, Nuutti Kotivuori wrote:
> Then again - "cvs update -j" is used for *merging*. It is confusingly
> the same command name, but it is really a merge operation. "cvs update
> -j" can be used to port changes between branches and the codeline, and
> can be used to rebase a branch.
Yes - that is the usage I meant (sorry about that). I
understand cvs update has several uses. One of which is simply
to update/refresh a workspace with the "latest stuff" from the
"right" codeline, typically before beginning work on a new task
(so I can reuse the current sandbox rather than scrap it and
make a new one) and another is to port/rebase changes from
the trunk (including merging any parallel changes)
> In the original context where I used that expression it is all pretty
> much the same. The whole point is that after a commit to the mainline,
> there are no changes in the branch that are uncommitted - so
> "rebranching" is only to let the version control system know that
> further changes are against the mainline at that point, and not
> against the last edit on the previous change done on the branch -
> there are no changes to merge, just metadata to inform.
Right! (thank you for stating it so clearly). So what I'm
seeing is that while SVN does indeed support change-sets,
there is an implicit assumption by "svn log" that historical
information about a branch starts with the beginning of the
branch, and while there may be revisions of a branch that
correspond to change sets, the notion that multiple successive
revisions on the branch may be part of a larger task that are
"delivered to the trunk" as a whole, doesn't really transport
across branches.
The trunk knows that the stuff committed to it since the
previous trunk revision is all one group. But the branch from
which those changes came has no knowledge of that. The branch
just knows about commits to itself, not bundles of changes-sets
merged from/to some other branch.
So I hear you telling me that the only way to tell a branch
that it should "reset" it's history-logger after it's been
"resynced" with the codeline is to explicitly "rebranch" it
so that it thinks its branch-off point is the new-tip of the
trunk instead of a previous one.
The other interesting thing is that the branch name apparently
is not associated with the revision on the trunk that resulted
from merging that branch to the trunk. So folks that created
a branch for a specific task in their tracking system (e.g.
bugzilla or Jira or scarab, etc.) who may have used the task-id
in the branch-name, often expect that branch-name (containing
the task-id) to somehow "live on" in the history of the trunk
once the changes are merged to the trunk.
It seems they don't get that right now, based on a recent
request I saw about wanting the ability to create some kind
of "alias name" for a revision number that is separate from
the notion of a "tag" (which I can fully understand, tho I
agree calling it a "tag" rather than a revision alias would
cause confusion, or perhaps a "Name" property of a revision,
if properties can be associated with a revision)
> Is there a reason why one should not delete a private branch after a
> commit to the mainline, and recreate it when starting a new one?
Why recreate the branch rather than create a new branch by
a new name? If you delete it and then recreate it, I would
say that you are, in essence, still using the private branch
pattern, where the rebranching is part of a tool-implementation
specific tactic for "delivering" changes from the private branch
to the trunk that also tells the "delivering" branch it is now
"resynced" as far as history is concerned.
If I create a new branch for a new task instead of reusing
(via deleting and then rebranching with the same name), then it
is either because I still want the branch-tag to be associated
with the delivered set of changes and their history, or because
I still want the associated storage or sandbox. It seems I can't
get the former (the delivered changeset => name association)
without the latter.
> I
> mean, sure, you can keep on editing in the same branch, you can use
> revisions to mark ranges, you could build support into Subversion to
> record the latest commit and only show diffs and logs until that and
> smart merging will save your ass if you merge changes twice - but why
> bother? Is there something to be gained by all that?
The reason for doing that instead of a new-branch per task
would be if I could still get the benefits of task-based
change-set grouping without having to create so many additional
branch-names and associated "copies". If I could reuse the
"copy", and let the "name" be associated with revision resulting
from porting the changes to the trunk, then I'm still creating
new names (that get associated with trunk revisions) but I'm not
creating new branches/tags nor their associated copies, and
the version tree has a much simpler structure, and I'm still
doing a whole lot less copying (even tho it is a lightweight
operation, its still not as lightweight as not doing it at all)
Plus there is a different between being lightweight,
and being "perceived" as lightweight. For some folks,
no matter how well you explain to them that branching in
SVN is inexpensive+lightweight, it still seems conceptually
"heavyweight" to them. And even if the implementation of doing
so is lightweight, it will still seem conceptually more complex
(as will having to delete+rebranch, something they would regard
as an indication of additionally technical "residue" required
by the additional conceptual complexity, for something they
see as not being necessary in the first place).
But I think the answer to your question is that with SVN, what
you described (deleting+rebranching) is really just part of the
SVN implementation of using a "private branch" (assuming you are
still using the same branch-name when you rebranch). I had thought
you were doing something more like the "task branch" pattern,
and wondered why not "reuse" the existing branch rather than
create a new branch by a new name. It sounds like that's not what
you're doing.
In SVN, because branches and tags are both "copies", it can
be difficult to discuss branching and labeling concepts in
ways that treat both as separate/separable things (and that
is essentially one of the main differences between a private
branch and a task-branch. One reuses the work-stream and the
work-space, while the other creates a new work-stream and
workspace for the purpose of keeping the branch0name around
as a mnemonic for the revision corresponding to the delivered
change-set)
--
Brad Appleton <brad@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 22 18:08:57 2004