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.
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")
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).
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?
> 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?
> 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). 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)
> 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 :-(
--
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 Sun Mar 14 08:40:25 2004