[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PROPOSAL] Merging Improved

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2003-04-11 20:49:14 CEST


I like the proposal! A few comments -- I've read the whole thread up
to this point, so some of this is really in response to subsequent

   1. Instead of [UUID::]PATH@REV[:REV], how about [UUID]:REV[-REV]:PATH ?
      That way, we keep all the fixed-format stuff up front, and the
      most variant component (the path, which might even contain "@")
      always comes after the second colon. Easier to parse, and also
      probably easier to read when lined up in a column. You may
      laugh, but such things make a difference :-).

      Using a hyphen to indicate revision ranges seems more readable,
      and (in this format) would be easier to parse anyway.

   2. Please let's not add levels of indirection :-). No matter how
      smart we try to be, sometimes humans will have to read, and
      perhaps even edit, these properties. So let's use paths, not
      node-ids; and use real UUIDS -- even though they're longer --
      rather than indices into some particular repository's `uuids'

      (And if this was the only purpose of that table, that in itself
      is no argument for using indices in the property.)

      The more self-contained and repository-independent this
      information is, the less trouble we'll have down the road. The
      points about dump/load cycles are just one of many problems that
      could result if we don't store the information in its most
      basic, canonical form, imho.

   3. Regarding the question of whether to store the property on
      files/dirs unaffected by the merge, my instinct is not to.

      To get a feel for this, I tried reasoning about an extreme case:
      you do a merge and absolutely no files are affected. In that
      case, it would be equally correct to store no properties, or to
      store a property on every file indicating that the merge was
      done. But in the latter case, we'd really be recording the mere
      fact that someone had typed 'svn merge'. The merge would have
      had no real-world consequence at all, and yet all these
      properties would change. This seems inconsistent with other
      Subversion operations, where if they do nothing, then no change
      is recorded in the repository. Also, it would use up space for
      no reason :-).

That's all. Frankly, I'd be +1 on this going in right now, as long as
it starts out experimental (i.e., a flag to merge, that later can
become the default).


"Sander Striker" <striker@apache.org> writes:

> > From: Branko Cibej [mailto:brane@xbc.nu]
> > Sent: Friday, April 11, 2003 8:47 AM
> > Jack Repenning wrote:
> >
> >> This all depends on having svn:merged props to record the merge history.
> >> But is there always somewhere to park that property when you need it?
> >> Something here I'm not quite following, probably because I haven't fully
> >> grokked a more basic question ... So I'll ask that one:
> >>
> >> If you merge a URL into your WC, some files will change and others will
> >> not. Can you attach a new svn:merged to all the files in the WC, even
> >> the unchanged ones, without losing any existing svn:merged?
> >
> > If the file didn't change, you don't have to record any merge history.
> > You can, of course, and it doesn't hurt, but it's not necessary to the
> > proposed algorithm.
> Right. For consistency I was thinking to always record the merge in
> svn:merged-from, even on unchanged files. Then again, we do not
> need it and it is unrequired overhead...
> There is a use case for recording svn:merged-from for files that haven't
> changed though. We might want to tell merge we want to sync up to
> branch@Y (MRMR = branch@X), but to ignore all changes. This way you
> can avoid certain changes on 'branch', since next merge will be from
> branch@Y to branch@HEAD, effectively bypassing the changes in
> branch@X:Y. And yes, we do need an extra switch to pass to svn merge
> for that. Ofcourse you can argue that this use case does have changed
> files, namely on branch (MRMR:L), instead of the working copy (M:WC).
> Sander
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 11 21:32:39 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.