news <news@sea.gmane.org> writes:
> Jens Scheidtmann wrote:
> >> from trunk@HEAD (which is e.g. revision 200) to feature_branch@HEAD?
> >> Shouldn't that be the other way around (the lower revision first)?
> > But as the feature branch@HEAD contains the changes local to it
> > *PLUS* the changes on trunk since the branch was made,
> >
> > From: TRUNK @ HEAD <-
> > To : FEATURE_BRANCH @ HEAD <- Note same revision
> >
>
> This is what I find confusing. It looks to me as if
>
> merge from trunk@HEAD to feature_branch@HEAD into trunk WC is
> effectively setting trunk = feature_branch, so (assuming no local
> changes in WC) the WC now exactly reflects feature_branch@HEAD and
> discards any changes made to trunk since feature_branch was copied off.
No, you repetively merged changes on trunk into the feature
branch. ie. you did:
- WC = feature branch
- Merge
FROM: Trunk @ BRANCH_REVISION
TO : Trunk @ HEAD
... some more work on *both* branches ...
- WC = feature branch
- Merge
FROM: Trunk @ LAST_HEAD
TO : Trunk @ HEAD
... repeat ...
so effectively, feature branch already contains all changes on trunk
*PLUS* the feature itself.
> The net effect is to copy a different revision/tree from the repo over
> the top of the existing WC.
No:
TRUNK - - - - > BRANCH
| |
| |
@ REV X --------------> |
| |
| @ REV X + 2
| |
@ REV HEAD - 1 --------------> |
| |
| commit
| |
@ HEAD <------------- @ HEAD
| : work on trunk or feature
- - - > : Branch operation
------> : merging changes on trunk into Branch,
(which is equivalant to branching *at that later rev*, while
keeping the changes on the branch)
<------ : merge feature back into trunk
> Uses for this that I can see are:
>
> Took a branch too early, and now want to update it to reflect trunk@HEAD
> before starting work on it - but why not just delete the old one and
> make a new one.
Well, "took a branch to early" is exactly what the feature branch wants
to solve. Ideally, the feature could be committed within one step.
Practically it takes to long and work has to start at a given point in
time. But you want to stay in close vicinity to the trunk. So you
repeat trunk's changes on the feature branch and later, when the
feature has become mature, you can merge the feature back into trunk.
> Trunk is Version 1, which is used only for bug fixes, and Version 2 is
> developed in a branch. At some point, trunk has to be updated to match
> the v2 branch. But this is backwards from normal usage, which keeps new
> V2 developments in the trunk and makes a branch at V1 for bug fixes.
feature branches are for concurrent development on V2, where a part of
the development teams works on the FB, while the other part works on
trunk.
In addition integration work is done on the branch and not on the
trunk, which in my eyes is cleaner (YMMV).
> To me these look like very uncommon use cases, so it should not be easy
> to do that accidentally.
For greater projects, I guess it's not so uncommon.
> I don't think we can get rid of having separate
> From/To URLs altogether, but I think we should make it invisible by
> default to avoid confusion.
Isn't using the same from and to url as default (as is the case now)
enough?
Jens
--
Jens.Scheidtmann@bayerbbs.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Jan 13 16:00:59 2005