On 8/3/06, Daniel Rall <dlr@collab.net> wrote:
> On Thu, 03 Aug 2006, Malcolm Rowe wrote:
>
> > On Thu, Aug 03, 2006 at 10:25:55AM -0700, dlr@tigris.org wrote:
> > > New Revision: 20951
> > >
> > > Modified:
> > > branches/1.4.x/subversion/include/svn_wc.h
> > > trunk/subversion/include/svn_wc.h
> > >
> >
> > So I guess I'm curious - what should a merge tracking solution do with
> > something like that, in general?
>
> This was a manual change and commit made to both branches (e.g. no
> merge), so we wouldn't be modifying any merge history here.
>
>
> > What do svnmerge and the current merge-tracking branch do?
>
> If the changes had been brought about by a merge into the WC, the
> current merge-tracking branch would've added to the merge history for
> both svn_wc.h paths during the merge, and persisted that to the repos
> upon commit.
>
> If this had been a merge, and all tags and branches our repository
> contained a similar merge (highly improbable, in this case), the merge
> info would be "elided" into the repository root ("/").
>
>
> svnmerge.py allows for tracking merge info only at a tree/branch root,
> meaning that merges for which you want to retain merge history must be
> whole branch (tree) merges (sub-tree merges aren't supported).
>
> Clear as mud, right? :-)
So if I tried to merge the portion of the commit from trunk into
1.4.x, the merge tracking code would have no way to determine that it
shouldn't be done, and a conflict would likely occur, right? So we
should just tell people not to do stuff like that if they want merge
tracking to be any good ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 3 22:24:01 2006