Sander,
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
discussion:
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'
table.
(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).
-Karl
"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