Phew, this message seems to be really hard to split in pieces since
every part refers to every other part. So, I left just enough context
on the comments to understand what it refers to, but read the original
mail to understand what is being talked about. Also, since I have a
bit of trouble with my mails, I don't know if somebody else already
answered this fully. And I'm also not so sure I know what I am talking
about.
Brad Appleton wrote:
> If you created a branch-per-task, then the branch is a grouping
> mechanism for your resulting change-set for that task.
Yes.
> Does SVN already have a grouping mechanism (independent from
> branches) that identifies what my change-set was and all the
> participating files and file-changes from the beginning-to-end of my
> task?
No. 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.
> If it has that (I had the impression it does), then do I need the
> branch to do that grouping on a per-task basis? Or can I just use it
> as a private workstream in which I work on one task at a time, each
> task having its own change-set which I can still identify and diff
> against as a change-set (rather than as an entire branch).
If you work on one task at a time, then the way you can get the entire
change-set for the task is to get a diff from the first revision
(commit, change-set) of the task to the last revision (commit,
change-set) of the task. That diff is then the combined change-set for
the task - and that is obviously what people do when they merge a
branch back to trunk. So you have to mark down (or check from history)
the revisions in a case like this.
>> Also, I wouldn't want the history from each feature to be muddled
>> with other ones -- something that happens if you don't delete the
>> branch.
>
> Why would that happen if you only work on one task at any given time
> in your branch and start start a new task until the previous one is
> completed?
It doesn't, as such - but since Subversions history (log) traverses
copies (branches) a few things happen.
If you have a branch created for a task, and some commits on it - when
you ask for log on the branch, you first get log messages for you
commits on the branch and then log messages for the trunk before the
point you branched from. If you ask log (history) to not traverse
copies, then you will get only the commit messages that you have made
on the branch - since it does not traverse back to the trunk.
But if you have a branch that survives several tasks in succession,
instead of getting logs for the current task and then logs for the
trunk, you get logs for the current task, then logs for every other
task performed in this branch and then the trunk. And if you ask log
not to traverse copies, you get commit messages for all tasks ever
performed on the branch.
Again, you can 'fix' this by supplying revision numbers, which gets
you only the current task commit messages.
> Each change should happen independently of the other ones - right?
> And the version of the codeline that you would want the subsequent
> change-task to be based off of is already right there in your branch
> and working-copy.
The version of the codeline that you want the subsequent change-task
to be based off is only the right one nobody else makes any changes in
the trunk in the meantime. Otherwise you want to refresh the version
of the codeline you wish to be working on top of from the head of the
development at that time, either by merging or copying.
> The private branch gives you your own private working-space and
> versioning-space (the branch) to checkout and checkin changes in
> isolation before committing them.
Yes.
> The existing change-set mechanism should give you the mechanism for
> identifying and referencing/comparing/diffing each individual change
> (unmuddled from the others since they were non-overlapping), and
> should be able to do that without needing the branch.
Only if you supply revision numbers to identify each task.
> Or am I misunderstanding/overstating what an SVN change-set
> does for you?
A bit.
>> But this doesn't make sense since I have now put two unrelated
>> features into the same work stream of my SCM.
>
> If you instead created a new branch, you would branch it off the
> trunk that already contained the changes for your previously
> committed task, yes? So then I'm thinking that in either case, the
> initial configuration of the codeline that is in your workstream at
> the beginning of that next task is identical either way.
Again, only if there are no intervening commits after you finished
your last task and before you started a new one. Otherwise you wish to
merge or copy those changes in before.
And yes, the contents of the working copy may be identical, but the
history is not. If you continue on working on the branch directly,
history will show that it is just further development on the same
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). Ofcourse since branches are so cheap and either
operation is just a simple 'svn cp' on URLs, it hardly matters if you
just rebranch your private workspace, or create a new branch.
> Is there something stopping me from telling svnlog to give me the
> history since my last commit (as opposed to since I created the
> branch)? Can I do that without having to create a tag if SVN tracks
> the change-set for my task-commit(s)?
Um. Yes, you can do that by specifying exact revision numbers.
> [It could be I don't have a good enough understanding of SVN here]
Okay, there is one big thing that is probably causing the confusion.
When you "commit" your entire change-set (that is the product of
several smaller change-sets, eg. commits most likely) to the mainline
of the development - which in Subversion is a merge operation - that
is then a change on the *mainline* (trunk) only! It does not affect
your branch in any way. Nothing tells the branch that "this task or
change-set is now finished". So when you keep on developing on the
same branch, it is as if you are still making changes on the old
change-set and only revision numbers can separate those changesets.
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.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Mar 13 01:10:51 2004