Branko Čibej <brane@xbc.nu> writes:
> >>3.2 Multiple indexes per revision
> >>
> >>The values of properties that allow multiple keys per single revision
> >>are represented in a newline-terminated list, one value per line (like
> >>the svn:ignore property on directories). Each value is added as a
> >>separate key to the index.
> >
> >I didn't understand this, sorry. Can you maybe give an example, or
> >try saying it another way? (Probably this is somehow related to my
> >earlier question about unique indexes.)
>
> I hope I answered this adequately in my other reply.
Yup, completely got it now, thanks.
> Not all metadata is associated with a commit (ACLs are an
> example). But apart from that, yes, if the metadata associated with a
> commit is mutable -- as it is in Subversion -- then it is indeed at
> odds with CM philosophy if changes to that metadata aren't
> tracked. Imagine someone changing the value of svn:author; don't you
> agree that is useful to know what the original value had been, and who
> made the change, and when?
Perfect example, yup.
> There's a nice paper that discusses some of these issues at
>
> http://www.accurev.com/accurev/info/timesafe.htm
Yah -- it looks like there's a lot of good stuff there, actually.
[Sigh. I'd give up my nights for another 12 hours in the day... Oh,
wait.]
The "timesafe" property is one that Subversion has been (informally)
trying to have. But we fall down in the revprop change area, yes.
> Anyway, I think we can postpone this part of the discussion until the
> 2.0 design phase (or at least take it to another thread).
Agreed.
> P.S.: For the record, I'd consider AccuRev to be our real competition
> going forward, rather than CVS (or BitKeeper). It has a totally
> outstanding SCM model.
Wish I were familiar with AccuRev :-).
The only other thing that still worries me in the labels proposal is
this (from another mail of yours in this thread):
> >If revisions have their dates out of order, then -r {date}:{date} will
> >evaluate to a revision range which does not reflect the date range. So
> >I think we're better off trying to enforce in-date-order revisions than
> >we are trying to make our system work with out-of-date-order revisions.
>
> No, I'm totally against enforcing the date order, for the reasons I
> stated. Instead we should just fix the API.
The "date-search problem" that Greg Hudson was talking about isn't
merely an issue of API, it's about implementation. The reason to
enforce ordered dates is so we can use binary search, to narrow down a
date range to a set of revisions very quickly. Otherwise, resolving
dates to revisions requires a full scan of the revisions table.
You probably know all this already; it's just still not quite clear to
me how your proposal solves the problem. Btw, I'm not advocating
enforced ordering of revision dates, merely stating that it's one way
to turn an O(N) problem into a O(logN) problem. The addition of a new
index table might do the same thing, without enforcing ordering. (Was
there such an index in your proposal, and I just missed it?)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 20 22:11:27 2004