Re: Date ordering of revisions

[Julian Foad <ju...@btopenworld.com>]

Branko Čibej wrote:
> Alan Barrett wrote:
> 
>> [...]  Under your proposed new regime, copying
>> svn:date properties will not be allowed if that would cause the dates
>> to become out of order, and that will happen very often when people use
>> svk mirrors in the usual way. [...]
> 
> This is yet another reason to resurrect my idea that we should introduce 
> a secondary index for dates, and enhance the date search routines. 

It sounds like you're suggesting a piece of implementation beneath the "find 
the last revision before a given date" interface, to make it work even if the 
dates are not in order.  That's fine as far as it goes - "svn log 
-r{2000-01-01}" would indeed then show the last revision having an "svn:date" 
before 2000 - but what would it mean, what would be the benefit, in a 
repository without strict ordering?  That's closely related to my last 
paragraph below.

The problem is that the "last revision before a given date" interface itself is 
not very useful in that situation, as far as I can see.  Do you have an idea 
for a new API and high-level functionality that would make use of your indexed 
date look-up function?

> The requirement that svn:date ordering == revision ordering is too restrictive.

Too restrictive for what?  (Genuine question, for anyone who feels like 
tackling it.)  What exactly is it that people want to do with non-sequential 
dates, or rather (perhaps) dates that are only sequential within some 
particular subsets of the node-path space of the repository?

Alternatively, I could ask this way: If "svn:date" is not necessarily going to 
be the date of commit to this repository, then what is it going to mean?  There 
doesn't seem to be any point in having a dedicated short-cut ("-r{DATE}") for 
operating on it unless we can specify what it means.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Date ordering of revisions

[Marc Sherman <ms...@projectile.ca>]

Julian Foad wrote:
> 
> Alternatively, I could ask this way: If "svn:date" is not necessarily
> going to be the date of commit to this repository, then what is it
> going to mean?  There doesn't seem to be any point in having a
> dedicated short-cut ("-r{DATE}") for operating on it unless we can
> specify what it means.

It seems to me that it might be useful to support ordered dates within a
particular subtree explicitly with a property (svn:date-ordered).
Within a subtree with that property set, svn would enforce strict date
ordering, and -r{DATE} would only be allowed within such a subtree.

- Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Date ordering of revisions

[Garrett Rooney <ro...@electricjellyfish.net>]

On 1/16/06, Julian Foad <ju...@btopenworld.com> wrote:

> Too restrictive for what?  (Genuine question, for anyone who feels like
> tackling it.)  What exactly is it that people want to do with non-sequential
> dates, or rather (perhaps) dates that are only sequential within some
> particular subsets of the node-path space of the repository?

Personally, I'd like it if the ordering was only necessary within a
particular subtree.  If all the dates are in order for everything
under a specific directory (which holds a project), then I should be
able to use svn log with a date revision specification on that
subtree.  The trick is finding a way to error out gracefully in the
situation where you're given a path that's not under such a
directory...

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Date ordering of revisions

[Branko Čibej <br...@xbc.nu>]

Peter Samuelson wrote:
> [Branko Cibej]
>   
>> svn:date should be the date when a changeset was created, not
>> necessarily in "this" repository.
>>     
>
> For dump / load this makes sense, but how far do you want to take it?
> For example, suppose a client is written which can take a GNU patch
> file and commit it directly without the intermediate use of a working
> copy.  Should it force svn:date to the timestamp on the patch file?
> That seems wrong to me.
>   
This is certainly something that should be discussed on a case-by-case 
basis.

> As for revisions being chronologically ordered, the obvious solution is
> floating point revision numbers, so that new ones can be inserted
> between existing ones.  (:
>   
Grrr. Start running, I'm out to get you. :)

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Date ordering of revisions

[Peter Samuelson <pe...@p12n.org>]

[Branko Cibej]
> svn:date should be the date when a changeset was created, not
> necessarily in "this" repository.

For dump / load this makes sense, but how far do you want to take it?
For example, suppose a client is written which can take a GNU patch
file and commit it directly without the intermediate use of a working
copy.  Should it force svn:date to the timestamp on the patch file?
That seems wrong to me.

As for revisions being chronologically ordered, the obvious solution is
floating point revision numbers, so that new ones can be inserted
between existing ones.  (:

Re: Date ordering of revisions

[Garrett Rooney <ro...@electricjellyfish.net>]

On 1/17/06, Branko Čibej <br...@xbc.nu> wrote:

> Well, SVK already seems to have problems because of this. cvs2svn is an
> order of magnitude more complicated than it would have to be if revision
> ordering and date ordering weren't necessarily the same. Repository
> synchronisation (svnsync) probably has hidden issues. Etc.

FWIW, svnsync doesn't have any issues at the moment, it copies the
svn:date revprops along with everything else, and only works if you're
copying the entire repository and you have to start with an empty one,
so there's no chance to get out of order unless your source is out of
order.  There will be problems later on if/when someone tries to use
ra_replay to copy part of a tree instead of the whole thing.

-garrett

Re: Date ordering of revisions

[Branko Čibej <br...@xbc.nu>]

Julian Foad wrote:

> Branko Čibej wrote:
>
>> Alan Barrett wrote:
>>
>>> [...]  Under your proposed new regime, copying
>>> svn:date properties will not be allowed if that would cause the dates
>>> to become out of order, and that will happen very often when people use
>>> svk mirrors in the usual way. [...]
>>
>>
>> This is yet another reason to resurrect my idea that we should 
>> introduce a secondary index for dates, and enhance the date search 
>> routines. 
>
>
> It sounds like you're suggesting a piece of implementation beneath the 
> "find the last revision before a given date" interface, to make it 
> work even if the dates are not in order.  That's fine as far as it 
> goes - "svn log -r{2000-01-01}" would indeed then show the last 
> revision having an "svn:date" before 2000 - but what would it mean, 
> what would be the benefit, in a repository without strict ordering?  
> That's closely related to my last paragraph below.
>
> The problem is that the "last revision before a given date" interface 
> itself is not very useful in that situation, as far as I can see.  Do 
> you have an idea for a new API and high-level functionality that would 
> make use of your indexed date look-up function?

http://svn.haxx.se/dev/archive-2004-04/0973.shtml

>> The requirement that svn:date ordering == revision ordering is too 
>> restrictive.
>
>
> Too restrictive for what?  (Genuine question, for anyone who feels 
> like tackling it.)  What exactly is it that people want to do with 
> non-sequential dates, or rather (perhaps) dates that are only 
> sequential within some particular subsets of the node-path space of 
> the repository?

Well, SVK already seems to have problems because of this. cvs2svn is an 
order of magnitude more complicated than it would have to be if revision 
ordering and date ordering weren't necessarily the same. Repository 
synchronisation (svnsync) probably has hidden issues. Etc.


> Alternatively, I could ask this way: If "svn:date" is not necessarily 
> going to be the date of commit to this repository, then what is it 
> going to mean?  There doesn't seem to be any point in having a 
> dedicated short-cut ("-r{DATE}") for operating on it unless we can 
> specify what it means.

svn:date should be the date when a changeset was created, not 
necessarily in "this" repository.

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org