You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2006/01/10 17:24:22 UTC
fsfs bug in commit timestamps?
It seems that while libsvn_fs_base sets the 'svn:date' revprop *both*
at transaction creation time and commit-finalization time,
libsvn_fs_fs only sets the property at creation time.
This is bad, isn't it? It could lead to revisions that are out of
date order, for example.
(I'm justifying my supposition by grepping for PROP_REVISION_DATE in
libsvn_fs_fs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: fsfs bug in commit timestamps?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
> At first glance, that seems to be the case... I'll see how easy it is to fix...
>
>
Looks pretty simple. There's one 'block' of code that fsfs takes out
an exclusive lock for... the same block which actually moves the
revision file into place. My guess is that's where svn:date should
also be set. That's where BDB is doing it, at least (in the bdb txn).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date ordering of revisions
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Re: Date ordering of revisions
Posted by 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 [was: fsfs bug in commit timestamps?]
Posted by Branko Čibej <br...@xbc.nu>.
Alan Barrett wrote:
> On Mon, 16 Jan 2006, Julian Foad wrote:
>
>>> When I mirror a remote repository, commits spread over several years in
>>> the remote repository can end up spread over a few minutes in the local
>>> mirror. If -r{DATE} can't do what I want, then I'd like some equally
>>> convenient syntax to refer to the original dates.
>>>
>> When you mirror a repository, there is no reason not to copy its existing
>> "svn:date" properties, so they won't be compressed into a few minutes, so
>> "-r{DATE}" can do what you want.
>>
>
> At present, that's true. 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. (Just mirror multiple remote repositories
> into different subtrees of a single local repository, or keep a local
> branch in the same repository as a mirrored branch, and wait long enough
> between sync operations to allow interleaved commits to happen.)
>
This is yet another reason to resurrect my idea that we should introduce
a secondary index for dates, and enhance the date search routines. The
requirement that svn:date ordering == revision ordering is too restrictive.
-- 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 [was: fsfs bug in commit timestamps?]
Posted by Alan Barrett <ap...@cequrux.com>.
On Mon, 16 Jan 2006, Julian Foad wrote:
> >When I mirror a remote repository, commits spread over several years in
> >the remote repository can end up spread over a few minutes in the local
> >mirror. If -r{DATE} can't do what I want, then I'd like some equally
> >convenient syntax to refer to the original dates.
>
> When you mirror a repository, there is no reason not to copy its existing
> "svn:date" properties, so they won't be compressed into a few minutes, so
> "-r{DATE}" can do what you want.
At present, that's true. 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. (Just mirror multiple remote repositories
into different subtrees of a single local repository, or keep a local
branch in the same repository as a mirrored branch, and wait long enough
between sync operations to allow interleaved commits to happen.)
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date ordering of revisions [was: fsfs bug in commit timestamps?]
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/17/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> On Mon, 16 Jan 2006, Julian Foad wrote:
>
> > Tony Overfield wrote:
> > From that message:
> > > While committing a long-running commit, if a shorter commit is started
> > > and completed before the long-running commit has finished, it creates
> > > unordered svn:date properties.
> > [...]
> > > I am using Windows XP with:
> > > svn, version 1.2.3 (r15833)
> > > compiled Aug 19 2005, 23:10:39
> >
> > Thanks for reporting it here now. It sounds like that's the bug found and
> > fixed recently (in trunk r18078) that's specific to FSFS; Berkeley DB
> > repositories don't have that bug.
> >
> > The fix does not appear to have been back-ported to the 1.3.x or 1.2.x
> > releases. I suggest we propose it for both. Yes, other committers?
> >
> +1. It is trivial.
FWIW, I just nominated the patch for 1.3.x, feel free to add your
votes to STATUS ;-)
-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 [was: fsfs bug in commit timestamps?]
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 16 Jan 2006, Julian Foad wrote:
> Tony Overfield wrote:
> From that message:
> > While committing a long-running commit, if a shorter commit is started
> > and completed before the long-running commit has finished, it creates
> > unordered svn:date properties.
> [...]
> > I am using Windows XP with:
> > svn, version 1.2.3 (r15833)
> > compiled Aug 19 2005, 23:10:39
>
> Thanks for reporting it here now. It sounds like that's the bug found and
> fixed recently (in trunk r18078) that's specific to FSFS; Berkeley DB
> repositories don't have that bug.
>
> The fix does not appear to have been back-ported to the 1.3.x or 1.2.x
> releases. I suggest we propose it for both. Yes, other committers?
>
+1. It is trivial.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date ordering of revisions [was: fsfs bug in commit timestamps?]
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/16/06, Julian Foad <ju...@btopenworld.com> wrote:
> Tony Overfield wrote:
> > I should have been more persistent, but I previously reported
> > this to the users list.
> >
> > See "Unordered commit dates from ordinary commits",
> >
> > http://svn.haxx.se/users/archive-2005-09/0599.shtml
>
> From that message:
> > While committing a long-running commit, if a shorter commit is started
> > and completed before the long-running commit has finished, it creates
> > unordered svn:date properties.
> [...]
> > I am using Windows XP with:
> > svn, version 1.2.3 (r15833)
> > compiled Aug 19 2005, 23:10:39
>
> Thanks for reporting it here now. It sounds like that's the bug found and
> fixed recently (in trunk r18078) that's specific to FSFS; Berkeley DB
> repositories don't have that bug.
>
> The fix does not appear to have been back-ported to the 1.3.x or 1.2.x
> releases. I suggest we propose it for both. Yes, other committers?
At the very least it should be backported to 1.3.x, 1.2.x probably
also makes sense. I hadn't proposed it yet because I wanted to give
people time to object if there was something wrong, but if you feel
it's ready feel free to put it in STATUS.
-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 [was: fsfs bug in commit timestamps?]
Posted by Julian Foad <ju...@btopenworld.com>.
Tony Overfield wrote:
> I should have been more persistent, but I previously reported
> this to the users list.
>
> See "Unordered commit dates from ordinary commits",
>
> http://svn.haxx.se/users/archive-2005-09/0599.shtml
From that message:
> While committing a long-running commit, if a shorter commit is started
> and completed before the long-running commit has finished, it creates
> unordered svn:date properties.
[...]
> I am using Windows XP with:
> svn, version 1.2.3 (r15833)
> compiled Aug 19 2005, 23:10:39
Thanks for reporting it here now. It sounds like that's the bug found and
fixed recently (in trunk r18078) that's specific to FSFS; Berkeley DB
repositories don't have that bug.
The fix does not appear to have been back-ported to the 1.3.x or 1.2.x
releases. I suggest we propose it for both. Yes, other committers?
> The book states that the svn:date property is set when the transaction
> is created, but wouldn't it be better to use the time at which the final
> revision number is obtained?
Ah, the book is misleading. It's strictly correct in what it says, as the
"svn:date" property is initially added at creation time (useful for an
administrator looking at the transaction before it is committed or if it fails
to be committed), but the book fails to say that "svn:date" is updated when the
transaction is committed.
Would you care to make a patch to correct the book XML file (en/book/ch05.xml,
section "svn.reposadmin.basics.revprops")?
- 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 [was: fsfs bug in commit timestamps?]
Posted by Tony Overfield <to...@yahoo.com>.
I should have been more persistent, but I previously reported
this to the users list.
See "Unordered commit dates from ordinary commits",
http://svn.haxx.se/users/archive-2005-09/0599.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date ordering of revisions [was: fsfs bug in commit
timestamps?]
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2006-01-16 at 10:13 +0200, Alan Barrett wrote:
> When I mirror a remote repository, commits spread over several years in
> the remote repository can end up spread over a few minutes in the local
> mirror. If -r{DATE} can't do what I want, then I'd like some equally
> convenient syntax to refer to the original dates.
One of the challenges of a distributed version control system is that
operating by date becomes difficult to define, if you're interested in
the original dates. "What changed between last Tuesday and last
Thursday" is no longer easy to say, since several different upstream
sources could have made different changes to different bases during that
time.
Does anyone have enough experience with another distributed version
control system (besides svk) to know how they handle the problem? I
think the answer is that they all punt.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date ordering of revisions [was: fsfs bug in commit timestamps?]
Posted by Julian Foad <ju...@btopenworld.com>.
Alan Barrett wrote:
>
[description of some of SVK's operation]
Thanks.
> Yes, the date issues with svk mirrors are essentially the same as with
> the "svnadmin load" situation.
>>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.
>
> When I mirror a remote repository, commits spread over several years in
> the remote repository can end up spread over a few minutes in the local
> mirror. If -r{DATE} can't do what I want, then I'd like some equally
> convenient syntax to refer to the original dates.
When you mirror a repository, there is no reason not to copy its existing
"svn:date" properties, so they won't be compressed into a few minutes, so
"-r{DATE}" can do what you want.
- 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 [was: fsfs bug in commit timestamps?]
Posted by Alan Barrett <ap...@cequrux.com>.
On Mon, 16 Jan 2006, Julian Foad wrote:
> If someone could briefly explain how SVK causes this misordering,
> without me knowing anything about SVK, that might be helpful.
A user's personal svk repository is really just a subversion repository,
and svk accesses it using the subversion perl bindings. svk allows you
to mirror remote subversion repositories to your local svk repository.
Each revision in the remote svn repository becomes a revision in
the local svk repository, but svk adds some extra properties for its
own purposes. Whenever you ask svk to sync the mirror, you will be
appending some old commits (copied form the remote repository) to your
local repository. The old commits may have svn:date properties that
are older than some other commits in (other subtrees of) your local
repository.
The above description deals with pulling changes from a remote
repository to a local repository. Pushing changes from a local
repository to a remote repository can also happen, but I am not sure
what svk does with the svn:date properties in that case.
> 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).
Yes, the date issues with svk mirrors are essentially the same as with
the "svnadmin load" situation.
> >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.
When I mirror a remote repository, commits spread over several years in
the remote repository can end up spread over a few minutes in the local
mirror. If -r{DATE} can't do what I want, then I'd like some equally
convenient syntax to refer to the original dates.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date ordering of revisions [was: fsfs bug in commit timestamps?]
Posted by Julian Foad <ju...@btopenworld.com>.
Garrett Rooney wrote:
> On 1/13/06, Julian Foad <ju...@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
Re: Date ordering of revisions [was: fsfs bug in commit timestamps?]
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/13/06, Julian Foad <ju...@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".
> Would we be prepared to agree and document something like?:
>
> * "svn:date" represents the date at which this revision was committed to this
> repository, and thus must increase monotonically.
>
> * If "svn:date" properties are out of order, up until at least Subversion v1.3,
> the only thing that breaks is "-r{DATE}", and in v1.x everything that works in
> v1.3 will continue to work but new features that rely on date ordering may be
> introduced.
>
> * If you want to record the date at which, for example, the files were
> originally committed to some previous repository, and the complete set of such
> dates would not be ordered in the current repository, then record those dates
> in some other property, not "svn:date".
>
> If we agree, we should do something about enforcing this in "svnadmin load" and
> "svn propset".
>
> To address the problems that people currently have with out-of-order
> repositories, we could write a "correction" utility which modifies the dates so
> that they are in order, possibly preserving the old values into a
> differently-named property if required. (This utility need only access the
> repository through the software API, though it could alternatively filter a
> dump file.)
>
> 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?
Additionally, what if I mirror a branch that was previously mirrored?
Now I've got three sets of dates to care about. How does that work?
-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 [was: fsfs bug in commit timestamps?]
Posted by Julian Foad <ju...@btopenworld.com>.
Vincent Lefevre wrote:
>
> More precisely, concerning "svn diff" and "svn merge", we would
> not have a set of revisions, but a set of couples of revisions
> (representing oriented intervals). Am I right?
Yes. When I said:
> it does make sense for "merge" to take an arbitrary set of revisions
by "revision" I meant a change, as in "the act of revising" rather than "the
result of revising".
- 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 [was: fsfs bug in commit timestamps?]
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2006-01-16 00:38:31 +0000, Julian Foad wrote:
> "svn diff" is similar to part of the operation of "svn merge". If we
> extend "svn merge" in this way, we ought for consistency to extend "svn
> diff" in the same way. What exactly would it do? I see two possibilities:
>
> (a) Try to combine the given changes in the same way that "merge" does, and
> possibly report conflicts.
>
> (b) Output a sequence of independent diffs in turn; any conflicts among
> them will be found at "patch" or "svn merge" time.
>
> I suspect (b) would be more useful, but haven't thought deeply about it.
I also think that (b) would be more useful, as a conflict here is
not necessarily an error: the user may just want to look at the
differences, but not apply any patch.
More precisely, concerning "svn diff" and "svn merge", we would
not have a set of revisions, but a set of couples of revisions
(representing oriented intervals). Am I right? With "svn diff",
there could be an option to decide how the changes are combined:
* The changes are fully combined; this would be (a), with a
possible error.
* The changes are combined in independent diffs, with a minimal
set of patches.
* There is a patch per change. In particular, this would allow to
see the successive changes on one or several files (it would be
a good complement to "svn blame").
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date ordering of revisions [was: fsfs bug in commit timestamps?]
Posted by Julian Foad <ju...@btopenworld.com>.
Vincent Lefevre wrote:
> On 2006-01-14 01:17:36 +0000, Julian Foad 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.
>
> BTW, what does svk do concerning svn:date?
I've no idea.
>>If we really want an ability to select a disjoint set of revisions based on
>>their properties, we should introduce a generic ability to select a set of
>>revisions based on any of their properties - e.g.:
>>
>> ((svn:date < 2000-01-01) OR (svn:author == julian)) AND (my:flag != "")
>
> Or "-r3977:3978,3998:4002". If I had this, I could have used one merge
> instead of two yesterday. :)
>
>>That sort of thing (especially filtering on svn:author) has been requested
>>before, specifically for "svn log" I think. I don't think there's
>>currently any other command that could sensibly make use of it.
>
> svn merge.
I didn't consider "svn merge" as a candidate for supporting an arbitrary set of
revisions because I was thinking that you cannot, in general, combine multiple
independent changes into a single change, because they might conflict with each
other. However, that's exactly what "svn merge" is designed to handle anyway,
so I was wrong: it does make sense for "merge" to take an arbitrary set of
revisions. It would apply each of the changes in turn (in some order, maybe
chronological, maybe the given order). This may result in conflicts, just like
a single-change merge can.
"svn diff" is similar to part of the operation of "svn merge". If we extend
"svn merge" in this way, we ought for consistency to extend "svn diff" in the
same way. What exactly would it do? I see two possibilities:
(a) Try to combine the given changes in the same way that "merge" does, and
possibly report conflicts.
(b) Output a sequence of independent diffs in turn; any conflicts among them
will be found at "patch" or "svn merge" time.
I suspect (b) would be more useful, but haven't thought deeply about it.
- 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 [was: fsfs bug in commit timestamps?]
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2006-01-14 01:17:36 +0000, Julian Foad 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.
BTW, what does svk do concerning svn:date?
> If we really want an ability to select a disjoint set of revisions based on
> their properties, we should introduce a generic ability to select a set of
> revisions based on any of their properties - e.g.:
>
> ((svn:date < 2000-01-01) OR (svn:author == julian)) AND (my:flag != "")
Or "-r3977:3978,3998:4002". If I had this, I could have used one merge
instead of two yesterday. :)
> That sort of thing (especially filtering on svn:author) has been requested
> before, specifically for "svn log" I think. I don't think there's
> currently any other command that could sensibly make use of it.
svn merge.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date ordering of revisions [was: fsfs bug in commit
timestamps?]
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2006-01-14 at 10:42 +0200, Alan Barrett wrote:
> Could we have a looser requirement, like
>
> * If "svn:date" properties are out of order when considering the
> repository as a whole, but you are performing a command that operates
> only on a subtree of the repository, and if "svn"date" properties
> are monotonically increasing over all revisions that affected that
> subtree, then "the right thing" happens.
That might be reasonable, but (1) that's not true today, (2) while it
sounds like a nice clear rule, it probably has ugly edge cases when you
try to actually apply it to every command in our command set, and (3) it
sounds difficult to implement efficiently.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date ordering of revisions [was: fsfs bug in commit timestamps?]
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 14 Jan 2006, Julian Foad wrote:
> Would we be prepared to agree and document something like?:
>
> * "svn:date" represents the date at which this revision was committed to
> this repository, and thus must increase monotonically.
>
> * If "svn:date" properties are out of order, up until at least Subversion
> v1.3, the only thing that breaks is "-r{DATE}", and in v1.x everything that
> works in v1.3 will continue to work but new features that rely on date
> ordering may be introduced.
>
> * If you want to record the date at which, for example, the files were
> originally committed to some previous repository, and the complete set of
> such dates would not be ordered in the current repository, then record
> those dates in some other property, not "svn:date".
Could we have a looser requirement, like
* If "svn:date" properties are out of order when considering the
repository as a whole, but you are performing a command that operates
only on a subtree of the repository, and if "svn"date" properties
are monotonically increasing over all revisions that affected that
subtree, then "the right thing" happens.
For example, when using svk, it's very common for some subtrees to represent
mirrors of remote repositories, and for some subtrees to represent local
branches. Dates are properly ordered within each subtree, but are not
globally ordered.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Date ordering of revisions [was: fsfs bug in commit timestamps?]
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Collins-Sussman wrote:
> On 1/13/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
>
>> We don't actually _rely_ on svn:date being a monotonically
>>increasing sequence anywhere, do we?
>
> 'svn subcommand -r{DATE}' depends on that assumption. It's a
> long-standing bug, see issue #752:
> http://subversion.tigris.org/issues/show_bug.cgi?id=752
The issue's summary line is "rev_hunt is broken when revisions are not
date-ordered". It acknowleges that there are two alternative solutions: either
make the dates ordered or make Subversion clients cope with unordered dates.
> Typically, this situation only happens when you load successive
> dumpfiles into a repository (i.e. merging histories together). The
> ASF has one giant repository, for example, which holds all their
> former CVS projects. They've just learned to live with the fact that
> -r{DATE} is unusable. But by committing this fix to FSFS, we've at
> least lowered the probability that the "unordering" can happen in
> normal, everyday use.
>
> It's really a design flaw. The problem that the server tries to
> translate -r{DATE} into a single revision by doing a binary search.
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.
Would we be prepared to agree and document something like?:
* "svn:date" represents the date at which this revision was committed to this
repository, and thus must increase monotonically.
* If "svn:date" properties are out of order, up until at least Subversion v1.3,
the only thing that breaks is "-r{DATE}", and in v1.x everything that works in
v1.3 will continue to work but new features that rely on date ordering may be
introduced.
* If you want to record the date at which, for example, the files were
originally committed to some previous repository, and the complete set of such
dates would not be ordered in the current repository, then record those dates
in some other property, not "svn:date".
If we agree, we should do something about enforcing this in "svnadmin load" and
"svn propset".
To address the problems that people currently have with out-of-order
repositories, we could write a "correction" utility which modifies the dates so
that they are in order, possibly preserving the old values into a
differently-named property if required. (This utility need only access the
repository through the software API, though it could alternatively filter a
dump file.)
Thoughts?
> To quote Greg Stein:
>
> "[...]if you have DATE1:DATE2, that becomes REV1:REV2. That is way
> wrong, as that revision "range" might not really be all of the
> revisions between the dates, or REV2 could even be earlier than REV1,
> or some of the selected revisions might not be in the date range.
> DATE1:DATE2 should really map to {R1, R3, R14, R7, ...}. IOW, some
> ordered list of arbitrary revisions. The client is NOT set up for that
> at all, not to mention all the server and transport bits necessary to
> provide it."
Indeed. And I don't see any reason to try to make that sort of thing work.
If we really want an ability to select a disjoint set of revisions based on
their properties, we should introduce a generic ability to select a set of
revisions based on any of their properties - e.g.:
((svn:date < 2000-01-01) OR (svn:author == julian)) AND (my:flag != "")
That sort of thing (especially filtering on svn:author) has been requested
before, specifically for "svn log" I think. I don't think there's currently
any other command that could sensibly make use of it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: fsfs bug in commit timestamps?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2006-01-13 at 09:27 -0600, Ben Collins-Sussman wrote:
> "[...]if you have DATE1:DATE2, that becomes REV1:REV2. That is way
> wrong, as that revision "range" might not really be all of the
> revisions between the dates, or REV2 could even be earlier than REV1,
> or some of the selected revisions might not be in the date range.
> DATE1:DATE2 should really map to {R1, R3, R14, R7, ...}. IOW, some
> ordered list of arbitrary revisions. The client is NOT set up for that
> at all, not to mention all the server and transport bits necessary to
> provide it."
Of course, even this is too simplistic. What does "svn diff -r
{1,3,14,7,...}" mean?
I like the semantics we have, even if they only work for linearly
date-ordered revisions. I think a repository with non-date-linear
revisions has no well-defined date semantics for the Subversion command
set; the dates on such a repository become descriptive metadata but not
indexable metadata, not as a trivial artifact of our implementation but
in a deeper, inherent sense.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: fsfs bug in commit timestamps?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 1/13/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> We don't actually _rely_ on svn:date being a monotonically
> increasing sequence anywhere, do we?
'svn subcommand -r{DATE}' depends on that assumption. It's a
long-standing bug, see issue #752:
http://subversion.tigris.org/issues/show_bug.cgi?id=752
Typically, this situation only happens when you load successive
dumpfiles into a repository (i.e. merging histories together). The
ASF has one giant repository, for example, which holds all their
former CVS projects. They've just learned to live with the fact that
-r{DATE} is unusable. But by committing this fix to FSFS, we've at
least lowered the probability that the "unordering" can happen in
normal, everyday use.
It's really a design flaw. The problem that the server tries to
translate -r{DATE} into a single revision by doing a binary search.
To quote Greg Stein:
"[...]if you have DATE1:DATE2, that becomes REV1:REV2. That is way
wrong, as that revision "range" might not really be all of the
revisions between the dates, or REV2 could even be earlier than REV1,
or some of the selected revisions might not be in the date range.
DATE1:DATE2 should really map to {R1, R3, R14, R7, ...}. IOW, some
ordered list of arbitrary revisions. The client is NOT set up for that
at all, not to mention all the server and transport bits necessary to
provide it."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: fsfs bug in commit timestamps?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/13/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> On Tue, Jan 10, 2006 at 02:52:19PM -0800, Garrett Rooney wrote:
> > On 1/10/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> >
> > > Looks pretty simple. There's one 'block' of code that fsfs takes out
> > > an exclusive lock for... the same block which actually moves the
> > > revision file into place. My guess is that's where svn:date should
> > > also be set. That's where BDB is doing it, at least (in the bdb txn).
> >
> > Yeah, that's what I came up with. Here's a patch that looks like it
> > should fix it. Seems to work, haven't done any really heavy duty
> > testing on it, so if someone with a little more fsfs background could
> > take a look I'd appreciate it.
> >
> > -garrett
> >
> > Reset svn:date before finalizing commits in fsfs so we can be sure that
> > the svn:date revprops remain ordered.
> >
>
> Ah, I had wondered where FSFS was updating the date. Yes, that patch
> looks sane to me as well. (I realise you've now committed it).
>
> Still, changing the svn:date property from 'transaction creation date' to
> 'transaction commit date' doesn't change much, does it, apart from the
> cosmetic issue of preventing time from going backwards for long-running
> transactions? We don't actually _rely_ on svn:date being a monotonically
> increasing sequence anywhere, do we?
Other people have answered the "We don't actually rely on that, do
we?" part, but as far as the "transaction creation date" ->
"transaction commit date" part, it's really supposed to be "commit
date", the "creation date" part was only put in as a convenience, so
that you can use it to tell if an uncommitted transaction is really
old, or if it's only been there for a few minutes. AFAIK anyway.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: fsfs bug in commit timestamps?
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 13 Jan 2006, Marc Sherman wrote:
> Malcolm Rowe wrote:
> >
> > Still, changing the svn:date property from 'transaction creation date' to
> > 'transaction commit date' doesn't change much, does it, apart from the
> > cosmetic issue of preventing time from going backwards for long-running
> > transactions? We don't actually _rely_ on svn:date being a monotonically
> > increasing sequence anywhere, do we?
>
> I seem to recall that when dates are given as -r params, a binary search
> is used to resolve them to rev numbers. So if the revs are out of
> order, the wrong rev might be chosen. I can't recall where I read this,
> though.
>
See libsvn_repos/rev_hunt.c, svn_repos_dated_revision().
Note that the change doesn't "make sure" that the dates are monotonically
incrementing, since the server's clock might be changed... But it improves
the situation, at least.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: fsfs bug in commit timestamps?
Posted by Marc Sherman <ms...@projectile.ca>.
Malcolm Rowe wrote:
>
> Still, changing the svn:date property from 'transaction creation date' to
> 'transaction commit date' doesn't change much, does it, apart from the
> cosmetic issue of preventing time from going backwards for long-running
> transactions? We don't actually _rely_ on svn:date being a monotonically
> increasing sequence anywhere, do we?
I seem to recall that when dates are given as -r params, a binary search
is used to resolve them to rev numbers. So if the revs are out of
order, the wrong rev might be chosen. I can't recall where I read this,
though.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: fsfs bug in commit timestamps?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Jan 10, 2006 at 02:52:19PM -0800, Garrett Rooney wrote:
> On 1/10/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
>
> > Looks pretty simple. There's one 'block' of code that fsfs takes out
> > an exclusive lock for... the same block which actually moves the
> > revision file into place. My guess is that's where svn:date should
> > also be set. That's where BDB is doing it, at least (in the bdb txn).
>
> Yeah, that's what I came up with. Here's a patch that looks like it
> should fix it. Seems to work, haven't done any really heavy duty
> testing on it, so if someone with a little more fsfs background could
> take a look I'd appreciate it.
>
> -garrett
>
> Reset svn:date before finalizing commits in fsfs so we can be sure that
> the svn:date revprops remain ordered.
>
Ah, I had wondered where FSFS was updating the date. Yes, that patch
looks sane to me as well. (I realise you've now committed it).
Still, changing the svn:date property from 'transaction creation date' to
'transaction commit date' doesn't change much, does it, apart from the
cosmetic issue of preventing time from going backwards for long-running
transactions? We don't actually _rely_ on svn:date being a monotonically
increasing sequence anywhere, do we?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: fsfs bug in commit timestamps?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/10/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> Looks pretty simple. There's one 'block' of code that fsfs takes out
> an exclusive lock for... the same block which actually moves the
> revision file into place. My guess is that's where svn:date should
> also be set. That's where BDB is doing it, at least (in the bdb txn).
Yeah, that's what I came up with. Here's a patch that looks like it
should fix it. Seems to work, haven't done any really heavy duty
testing on it, so if someone with a little more fsfs background could
take a look I'd appreciate it.
-garrett
Reset svn:date before finalizing commits in fsfs so we can be sure that
the svn:date revprops remain ordered.
* subversion/libsvn_fs_fs/fs_fs.c
(commit_body): Reset the svn:date revprop before moving the revprops
file into place when committing a revision.
Re: fsfs bug in commit timestamps?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/10/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> It seems that while libsvn_fs_base sets the 'svn:date' revprop *both*
> at transaction creation time and commit-finalization time,
> libsvn_fs_fs only sets the property at creation time.
>
> This is bad, isn't it? It could lead to revisions that are out of
> date order, for example.
>
> (I'm justifying my supposition by grepping for PROP_REVISION_DATE in
> libsvn_fs_fs...)
At first glance, that seems to be the case... I'll see how easy it is to fix...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org