Brad Appleton wrote:
> On Wed, Mar 17, 2004 at 01:46:55AM +0200, Nuutti Kotivuori wrote:
>> What is the term usually used to describe a single change (with a
>> log message usually) that has been "checked-in" to any branch?
>
> If its "checked-in" to a private-branch or a task-branch and
> the corresponding task is not yet finished, the common term
> I've heard (which the PrivateVersions pattern uses) is a
> "checkpoint", and the process of doing it is often called
> "checkpointing" (e.g., I've created a private "checkpoint"
> of my changes on my branch of my working-copy, but until I
> actually merge my changes to the codeline, I haven't really
> "committed" them (to the codeline) because theya rent yet
> visible to the rest of the team.
Okay, well, perhaps just talking about changes that are checked-in,
but have not been committed, will do.
>>> Why is it necessary to rebranch the branch (I assume you mean
>>> "reparent" the branch to a subsequent version of the trunk - which
>>> is almost what a "rebase" or "rebaseline operation does, in
>>> theory).
>>
>> Almost, but not exactly. "Reparenting" or "rebaselining" usually
>> means taking a change-set against an earlier version of mainline
>> (or baseline, heh), and adapting it to be against a later version
>> of mainline - eg. keeping the changes made on the branch, but just
>> making them be based against a later version of trunk.
>
> Okay. so for me, branch reparenting, rebranching, and branch
> rebaselining have a subtle but important difference.
Okay.
[...]
> * Rebasing (or Rebaselining) is "porting" the latest stuff from
> the codeline (trunk) into my branch. See slides 19-20 at
> http://www.cmcrossroads.com/bradapp/acme/clearcase/RUC2003_SCMA34.zip
> I thought that "cvs update" did the same thing?
Ah, I believe there is a tiny mixup here.
First of all - a plain "cvs update" is used to bring a working copy up
to date with the HEAD of the current branch. So assuming that there
are a bunch of changes as just local edits in the working copy
(changes that have not been checked-in or checkpointed), then yes -
"cvs update" does "port" the latest stuff from the codeline to the
working copy. However, if the changes are already checked-in or
checkpointed into a branch, "cvs update" does no rebasing what so
ever.
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. The results of the merge appear as
local edits though, so conflict resolution can be done, and the
results of the merge (or port) need to be checked-in or checkpointed
after that by "cvs commit".
[...]
I'm afraid I don't grok powerpoint, so your references were not of
much use for me. I believe to have some sort of an idea however.
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.
>> And again - smart merging only alleviates the merge conflicts and
>> allows you to do things differently, but it does not change the
>> logical issue here.
>
> Agreed. I don't usually see it causing any problems tho. But
> see the "Whole IS the sum of its parts" section of my earlier
> post - in those cases, it can be problematic.
Yes, with smart merging, there usually isn't a problem with it.
> Actually - I have read it, but its been a while (I think two
> years) and there have been changes, and I haven't been able to
> play with it to keep it fresh in my mind. Your examples were
> useful to me. Many thanks!!!
The conversation has been enlightening and helpful in seeing
alternative views and alternative terminology for the subject. Thank
you.
One small matter though which is a bit bugging me. We've talked here
how different things *can* be done in Subversion and how to handle the
problems resulting from some - but not the rationale behind it.
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? 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?
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Mar 20 23:39:42 2004