Brad Appleton wrote:
> On Sat, Mar 13, 2004 at 02:10:19AM +0200, Nuutti Kotivuori wrote:
>> Each commit is its own change-set and there is no way independent
>> from branches to group different commits (change-sets) into belong
>> to a certain task.
>
> Okay. I was assuming that the "stuff" in between commits
> constitutes a change-set at each commit. That much sounds correct.
Hm. I didn't quite understand this, but it sounds you mean the same
thing. Just in case there's any confusion, please read Subversion and
Changesets, at the end of the page here:
http://svnbook.red-bean.com/html-chunk/ch04s03.html#svn-ch-4-sect-3.2
> Where I think I go astray in is my use of "commit" versus
> Subversion's. They way I use "commit" and normally see it used, it
> refers to one's changes being checked-in to "the" codeline (not my
> private branch or task branch, but to the integration
> codeline/mainline that the rest of the team uses to see the latest
> and greatest "stuff")
Right. In Subversion (and CVS) lingo, "commit" is equal to "check-in"
and is used for all modifications that are transmitted to the
repository.
What is the term usually used to describe a single change (with a log
message usually) that has been "checked-in" to any branch? I will
continue to use commit in Subversion terms below, unless otherwise
noted.
> So I had assumed there was an easy way to tell "svn log" to show me
> all the stuff on my branch since the most recent commit to the
> codeline. Sounds like this is not the case (bummer).
Again, Subversion (and CVS) lingo calls this operation merging, or
porting, the changes from the branch to the trunk.
> Which means, as a previous poster pointed out, I need to tag every
> commit I do on the mainline, and every intentional "checkpoint" on
> my own private branch. I want to believe there is some easier way
> than this - is there?
Ascii art time! Whoop-pahh! (mangled from design document)
_____ _____ _____ _____ _____ _____
| | | | | | | | | | | |
| A:1 |-->| A:2 |-->| A:4 |-->| A:6 |-.->| A:7 |-.->| A:9 |
|_____| |_____| |_____| |_____| | |_____| | |_____|
\ / |
\ / |
\ _____ _____ / _____ |
\| | | | / | | /
| B:3 |-->| B:5 |-->| B:8 |->-'
|_____| |_____| |_____|
Here, let's assume that "A" is "the" codeline, or trunk, or whatever,
and "B" is your private branch. If you are at a working copy of B
which is at revision 5, and issue "svn log", you will get log messages
for B:5, B:3, A:2 and A:1. If you instead issue "svn log
--stop-on-copy", you will get only B:5 and B:3. Then again if you are
at a working copy of B which is at revision 9, and issue "svn log",
you will get log messages for B:8, B:5, B:3, A:2 and A:1. And if you
issue "svn log --stop-on-copy", you will get B:8, B:5 and B:3. But if
you wish to obtain only the difference since your last merge (or
commit to mainline), you have to explicitly say "svn log -r HEAD:5" in
the working copy.
Now consider the alternative, where the branch *is* deleted, and
re-created:
_____ _____ _____ _____ _____ _____
| | | | | | | | | | | |
| A:1 |-->| A:2 |-->| A:4 |-->| A:6 |-.->| A:7 |--------.->| A:9 |
|_____| |_____| |_____| |_____| | |_____| | |_____|
\ / \ |
\ / \ |
\ _____ _____ / \ _____ |
\| | | | / \| |/
| B:3 |-->| B:5 |- | B:8 |
|_____| |_____| |_____|
Here, the usage does not differ, and nobody needs to provide manual
revision numbers.
>> Again, you can 'fix' this by supplying revision numbers, which gets
>> you only the current task commit messages.
>
> That should work, at least for the commits on my own branch (which
> is perhaps good enough). Is there some "builtin" notion of
> "previous" or "last" (or MRC), which refers to the revision of the
> most-recent-commit on the "current" or named branch? (that sure
> would be nice). I'd love to be able to associate a name/alias with
> those and other revision numbers without having to create a "copy"
> in order to tag. Can I do this?
The revision number of the latest change (eg. latest commit in
Subversion terms) in the branch of the current working copy is called
COMMITTED. The revision before that is PREV. But there is no tag or
anything for the merge done to the mainline.
>> branch, nothing more. If you wish to Subversion that the next
>> commit is not a change-set on top of the old changes, but a
>> change-set against the trunk again, you need to re-branch the
>> branch (what a twist of words).
>
> 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.
What I meant was an operation equivalent to simply deleting the
current branch and creating it again with the same name from trunk.
> If I did an update to "rebase" my WC on my branch, why can't that
> have the same effect? (is it related to why SVN can't do "smart"
> merging - yet)
Um, now this is getting really confused. What does a working copy have
to do with this whole thing? And "update" is again a bad choice of
words since Subversion uses update to bring a working copy up to date
with changes committed in the repository mainline or branch. It does
not bring in changes from other branches (or the mainline) than which
the working copy is in.
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.
>> So, what you do in Subversion is to signify that the new commits
>> you are making again changes against the mainline of the
>> development, and not against your earlier change by... you guessed
>> it... re-branching.
>
> Ouch! Me no like that :-(
To re-cap the whole thing, let's look at the pictures above again.
In the first figure, revision B:8 is based against B:5, so all of
Subversion handles it as such - a successor of B:5 - and is totally
unaware of the merge (or commit to mainline as by your terminology)
that was committed as A:7. Hence you must specify in everything you do
that you are interested only in changes (or log messages) that
happened since B:5.
In the second figure, revision B:8 is based against A:7, so it is
already totally independent of the earlier changes made in the branch
and it is handle by what it actually is - an separate change against
the trunk again.
***
I believe a lot of the confusion here is about terms and such - and
the rest is about how Subversion handles change-sets and
branches. Both of these issues would probably become clear as water by
reading the Subversion book. It really isn't that bad of a a read -
and if you are looking to cut time, reading just Chapter 4 should be
enough, with first peeking through Chapter 2 Section 3.2 in case
there's something uncertain as to what revisions in Subversion
actually mean.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 17 00:47:19 2004