Garrett Rooney wrote:
> On 1/13/06, Julian Foad <julianfoad@btopenworld.com> wrote:
>
>>That's one view. I prefer to think that monotonic ordering of svn:date is a
>>requirement, and that a repository that violates the requirement is broken.
>
> You're welcome to that view, but it doesn't change the fact that there
> are a number of situations where that sort of thing happens (be it
> from importing converted dump files or svk style remote branches), and
> I don't think we can just say "don't do that".
If someone could briefly explain how SVK causes this misordering, without me
knowing anything about SVK, that might be helpful. Is it just that SVK stores
a sequence of changes locally and then later commits them to the (master)
Subversion repository but alters "svn:date" to the locally stored value? If
so, that's logically just like the "svnadmin load" situation, appending to the
present repository a series of old commits. We'd have to decide how to handle
that situation anyway (see below).
[...]
>>Thoughts?
>
> If we're going to have two separate types of date props, some for the
> original commit and some for the commit to this repos, then how do you
> tell the -r flag which one you're concerned about?
I don't envisage "-r{DATE}" operating on anything but "svn:date" which is (in
my proposal) guaranteed ordered. Any other date properties (e.g. "original"
commit dates to previous repositories, which may be multiple) are just more
metadata, and if you want special facilities for searching them, that's a
separate enhancement request, like the extended property-search revision-set
facility that I mentioned afterwards.
Therefore there are not two types of date properties, but (at the Subversion
library level) only "svn:date" versus arbitrary user-defined properties.
> Additionally, what if I mirror a branch that was previously mirrored?
If you're asking about SVK specifically, I've no idea. I'll take this as a
generic question.
> Now I've got three sets of dates to care about. How does that work?
"svn:date", defined as the date of commit to this repos, is what "-r{DATE}"
operates on. Until svn/Subversion gets its own notion of mirroring,
preservation of any other dates is the job of the mirroring tool. It's not a
new problem introduced by my proposal - it's the same problem that tools like
"cvs2svn" already have to consider. If the tool is able to put the old dates
into "svn:date" without violating ordering, thereby creating a repository which
LOOKS AS IF it had received commits at those dates, it is free to do so; if it
can't, and the user wants the old dates stored, it must use a different property.
Of course, we'll need to decide what "svnadmin load" does when appending a dump
file to an existing repository. Maybe it should set "svn:date" to <now> and
put those old dates in some hard-coded property (poor example:
"svn:date-from-dump") and then leave the user to delete or move this
information by using a separate script if desired. Maybe it should use the old
"svn:date" as much as it can, but limiting it to between <latest "svn:date" so
far> and <now>. Maybe the handling of dates from the dump file should be
user-defined.
We'll also need decide how to handle rev-prop changes that attempt to put
"svn:date" out of order. For a user interaction, I'm sure we could decide to
return an error, but for the API that is used (presumably) by SVK and the like,
we might be stuck until Subversion v2.
I suppose I should pick one option from each of these choices or decisions and
see if I can make a more complete proposal. Maybe I will, maybe not.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 16 02:47:39 2006