On Mon, Apr 14, 2008 at 2:41 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>
> On Sat, Apr 12, 2008 at 3:56 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> > On Sat, Apr 12, 2008 at 3:28 PM, Eric Gillespie <epg_at_pretzelnet.org> wrote:
> > > "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu> writes:
> > >
> > > > I didn't merge the whole branch, because I only wanted the modifications
> > > > to CHANGES, not to the whole branch. Whether or not that was the right
> > > > decision can be debated, but, hey, it's version control: we can
> > > > always grab the other parts of r30112 later if we need them.
> > >
> > > Merging just one file from trunk is a perfectly valid use case;
> > > it's the natural way to maintain such a file. I don't think you
> > > did anything wrong.
> >
> > He didn't do anything wrong. However, if you do a single file merge
> > than we have to record mergeinfo for that so that Subversion correctly
> > knows that you did not merge the other files from that revision. If
> > you know that you will never want to merge the other files from that
> > same revision and you are annoyed by the extra mergeinfo that was
> > created, then you have to manually tell Subversion that you merged the
> > entire revision. In theory, I would expect a --record-only merge of
> > the revision to the proper parent folder to elide away the
> > file-specific mergeinfo. I am not sure if it actually does that or
> > not, in which case you might need to propdel the property from the
> > files in addition to the --record-only.
>
> Right now the behavior of --record-only merges is really simple. No
> elision is attempted. Not only that, but we only record mergeinfo on
> the merge target; subtrees of the target with their own explicit
> mergeinfo are ignored.
>
> This begs the question: "Should --record-only merges take this minimal
> 'only what you ask' for approach or should handle subtrees with
> explicit mergeinfo and attempt elision?"
>
> ~~~~~
>
> As to what to do about the particular mergeinfo we currently have on
> 1.5.x/CHANGES, I see three options. From most to least prefferable
> they are:
>
> A) Leave it alone. We made legitimate merges directly to CHANGES, so
> why wouldn't it to have it's own mergeinfo?
>
> If we really want to get rid of the explicit mergeinfo we can:
>
> B) Repeat the merge of r30012 to the root of 1.5.x. The mergeinfo on
> CHANGES only differs by that single revision from the mergeinfo on
> 1.5.x so it would elide away. Yes, we get the changes to
> 'www\svn_1.5_releasenotes.html' but so what?
>
> C) Do the aforementioned merge and revert only
> 'www\svn_1.5_releasenotes.html' before committing.
>
> I don't like C) much since the mergeinfo
> 'www\svn_1.5_releasenotes.html' inherits from 1.5.x will obviously be
> incorrect. I know, I know, who cares? What does it matter? In this
> case the answers are "nobody" and "not much", but why *purposefully*
> set incorrect mergeinfo?
I'd probably vote for B. You had a typo in the revision by the way.
It is r30112. I just did the merge to my WC to try it out. You get
some conflicts in the release notes, but they are fairly easy to
resolve. It was good to see the elision stuff worked.
I am not sure about the --record-only. It seems like if it does not
do elision, then we are making it harder for people to "fix" these
situations. At the same time, in the back of my mind I recall this
being discussed last year and we said it shouldn't. I could be
misremembering that.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-14 21:29:02 CEST