You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2003/03/18 07:36:35 UTC
svn:original-date (was: svn commit: rev 5369 - trunk/subversion/include)
I wanted to point out this commit for discussion on the list. I've spoken
about this idea with a number of people off-list, and the consensus has been
"yup. makes sense." Just wanted to validate that here, too...
I see at least two use cases for generating this property:
1) cvs2svn creates revisions into an existing repository. the date of the
youngest rev (call it R) in the repos is *later* than some of the CVS
commits. because of the time-ordering requirement on svn:date, cvs2svn
cannot create a rev before R, the original commit date cannot be applied
to the new rev. instead, it has to put "now" onto the rev, and then it
can use this property to record the original CVS commit timestamp.
2) you 'svnadmin load' a dumpfile that has revisions that are older than
revision R. again, the dates don't match, so you load the revisions, but
migrate their date to svn:original-date and just use "now" for the
newly-loaded revisions.
At the moment, I see tools like cvs2svn and ViewCVS using/displaying this
date. Where/how we filter it into the rest of SVN is definitely a larger
discussion. For example:
* do we encode this into 'svnadmin load' as suggested above?
* if a dumpfile has revisions with svn:original-date, but the new repository
is going to allow that date (e.g. the revisions up to R are not present in
the loading-into repos), do we toss the dumpfile's revision dates and go
back to the original-date?
* do we propagate this date across the wire?
* is there a future scenario where revisions do not need to be time-ordered,
so maybe this points to a flow in the current implementation?
* etc
Again, for now, I'm just looking to use this in "external" tools.
Cheers,
-g
On Tue, Mar 18, 2003 at 12:34:06AM -0600, gstein@tigris.org wrote:
> Author: gstein
> Date: Tue Mar 18 00:34:02 2003
> New Revision: 5369
>
> Modified:
> trunk/subversion/include/svn_props.h
> Log:
> * include/svn_props.h:
> (SVN_PROP_REVISION_ORIG_DATE): add new property definition
>
>
> Modified: trunk/subversion/include/svn_props.h
> ==============================================================================
> --- trunk/subversion/include/svn_props.h (original)
> +++ trunk/subversion/include/svn_props.h Tue Mar 18 00:34:02 2003
> @@ -256,6 +256,19 @@
> /** The fs revision property that stores a commit's date. */
> #define SVN_PROP_REVISION_DATE SVN_PROP_PREFIX "date"
>
> +/** The fs revision property that stores a commit's "original" date.
> + *
> + * The svn:date property must be monotonically increasing, along with
> + * the revision number. In certain scenarios, this may pose a problem
> + * when the revision represents a commit that occurred at a time which
> + * does not fit within the sequencing required for svn:date. This can
> + * happen, for instance, when the revision represents a commit to a
> + * foreign version control system, or possibly when two Subversion
> + * repositories are combined. This property can be used to record the
> + * true, original date of the commit.
> + */
> +#define SVN_PROP_REVISION_ORIG_DATE SVN_PROP_PREFIX "original-date"
> +
> /** @} */
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: svn-help@subversion.tigris.org
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date (was: svn commit: rev 5369 - trunk/subversion/include)
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Mon 2003-03-17 at 23:36:35 -0800, Greg Stein wrote:
> > Modified: trunk/subversion/include/svn_props.h
> > ==============================================================================
> > --- trunk/subversion/include/svn_props.h (original)
> > +++ trunk/subversion/include/svn_props.h Tue Mar 18 00:34:02 2003
> > @@ -256,6 +256,19 @@
> > /** The fs revision property that stores a commit's date. */
> > #define SVN_PROP_REVISION_DATE SVN_PROP_PREFIX "date"
> >
> > +/** The fs revision property that stores a commit's "original" date.
> > + *
> > + * The svn:date property must be monotonically increasing, along with
Just minor nitpicking: Intentionally, I read this comment before
your explaining words in the main body of the mail, and could not
make much sense of it. The reason was that I did not notice that you
referenced the behaviour of svn:date, while this comment is about
svn:original-date, despite re-reading it serveral times. At least,
until I read the rest of your mail.
How about a rewording. Something like "svn:original-date is meant to
be suplementary to the svn:date property, which must be..." - surely
not ideal, but you get the idea.
> > + * the revision number. In certain scenarios, this may pose a problem
> > + * when the revision represents a commit that occurred at a time which
> > + * does not fit within the sequencing required for svn:date. This can
> > + * happen, for instance, when the revision represents a commit to a
> > + * foreign version control system, or possibly when two Subversion
> > + * repositories are combined. This property can be used to record the
> > + * true, original date of the commit.
> > + */
HTH,
Benjamin.
Re: svn:original-date
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Branko Čibej wrote:
>
>> If we added an extra date->revision index, this
>> ordering wouldn't be necessary any more and we wouldn't need
>> svn:original-date.
>
>
> So svn:date would no longer mean "date of this revision" in the
> context of an SVN (as opposed to CVS) revision. I cannot see clearly
> whether this change to the semantics of svn:date is safe.
>
> For instance, assume a combination of regular SVN commits and
> back-dated CVS2SVN commits resulted in this history:
>
> r2 10 Jan Added foo.c
> r3 8 Jan Added bar.c
>
> Then I request:
>
> svn co --revision {"9 Jan"}
>
> Which file(s) will it check out? Which should it check out? This
> obviously isn't intended as a multiple-choice question, but a policy
> decision.
>
> I have no reason to uphold the requirement for svn:date to increase
> monotonically, except that I feel there may BE a good reason for it
> already.
Commits would be ordered by date *whithin a single branch* (remember,
this problem crops up with cvs2svn, not within SVN itself). What we'd
like to do is make it possible to commit a branch after having committed
the mainline (or, in the svnadmin load case, load older revisions into a
parallel tree). So your example would become:
r2 10 Jan Added /branches/foo/foo.c
r3 8 Jan Added /branches/bar/bar.c
And that's entirely acceptable, IMHO.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Mar 19, 2003 at 11:01:37PM +0000, Julian Foad wrote:
> Branko ??ibej wrote:
> >Greg Stein wrote:
> >>* is there a future scenario where revisions do not need to be
> >>time-ordered,
> >
> >As far as I know, there is exactly one reason why our commits must be
> >time-ordered: So that get_revision_by_date can do a binary search on
> >revision numbers.
>
> I don't have enough experience with this. Could someone else verify
> that that is the only reason?
Yup, it's true. We use a binary search to locate a revision for a given
date. That requires that the revs/dates are ordered.
> Is get_revision_by_date not used to find the beginning and end of a
> range of revisions (rX -> rY), with the assumption that this will be
> equal to the set of changes made between dates X and Y?
Hmm. Interesting point. I'm not sure that I truly follow the question, but
the point seems to be:
1) map date X to rev rX
2) map date Y to rev rY
3) the range [rX,ry] does not necessary correspond to
revs R where X < date(R) < Y
In other words, when the SVN client deals with a "range bounded by dates",
it is assuming that can directly translate to a revision range. But the
reality is that a date range can refer to an arbitrary assortment of
revisions in the repository.
For example:
$ svn log -r {march 1:march 3}
the revisions in that range could be rev 1, 10, and 307.
Sigh.
> >If we added an extra date->revision index, this
> >ordering wouldn't be necessary any more and we wouldn't need
> >svn:original-date.
>
> So svn:date would no longer mean "date of this revision" in the context
> of an SVN (as opposed to CVS) revision. I cannot see clearly whether
> this change to the semantics of svn:date is safe.
No no... nobody has suggested changing the meaning of svn:date. That
absolutely means the time when the revision was committed.
The question that I raised was that we might want to record the logical date
of a change, rather than when it was placed into the SVN repository. But
since svn:date must be ordered, that implies a separate property or the
alteration of the svn:date ordering requirement.
> For instance, assume a combination of regular SVN commits and back-dated
> CVS2SVN commits resulted in this history:
>
> r2 10 Jan Added foo.c
> r3 8 Jan Added bar.c
>
> Then I request:
>
> svn co --revision {"9 Jan"}
>
> Which file(s) will it check out? Which should it check out? This
> obviously isn't intended as a multiple-choice question, but a policy
> decision.
It should check out r3. That is the revision that was extent on Jan 9.
Of course, the interesting problem is when you also look at r1 in your
scenario:
r1 6 Jan Added bloo.c
r2 10 Jan Added foo.c
r3 8 Jan Added bar.c
When the repository only has r1 or r1..r2 in it, then you'll get a different
set of data for a "Jan 9 checkout" compared to after r3 has been committed.
> I have no reason to uphold the requirement for svn:date to increase
> monotonically, except that I feel there may BE a good reason for it already.
Very good points. Thank you.
I'm thinking that we shouldn't mess with a DATE->REVNUM index, and continue
to stick with the requirement that revisions must be committed in a
monotonically-increasing fashion.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Greg Stein wrote:
>
>>* is there a future scenario where revisions do not need to be time-ordered,
>
> As far as I know, there is exactly one reason why our commits must be
> time-ordered: So that get_revision_by_date can do a binary search on
> revision numbers.
I don't have enough experience with this. Could someone else verify
that that is the only reason?
Is get_revision_by_date not used to find the beginning and end of a
range of revisions (rX -> rY), with the assumption that this will be
equal to the set of changes made between dates X and Y?
> If we added an extra date->revision index, this
> ordering wouldn't be necessary any more and we wouldn't need
> svn:original-date.
So svn:date would no longer mean "date of this revision" in the context
of an SVN (as opposed to CVS) revision. I cannot see clearly whether
this change to the semantics of svn:date is safe.
For instance, assume a combination of regular SVN commits and back-dated
CVS2SVN commits resulted in this history:
r2 10 Jan Added foo.c
r3 8 Jan Added bar.c
Then I request:
svn co --revision {"9 Jan"}
Which file(s) will it check out? Which should it check out? This
obviously isn't intended as a multiple-choice question, but a policy
decision.
I have no reason to uphold the requirement for svn:date to increase
monotonically, except that I feel there may BE a good reason for it already.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by cm...@collab.net.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> >If DATE->REVNUM is more efficient, then +1 on that, and -0 on DATE->TXN_ID.
> >
> How about DATE->(TXN_ID [REVNUM])? Two stones with one bird. :-)
Redundancy, redundancy, yuck, yuck, yuck. But do whatcha want. Kinda
cool that this mapping's key is an apr_time_t, which is automagically
sortable (since it's just an integer value), though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>>Right after I put in the svn_filesize_t change.
>>
>>
>
>You haven't responded to my comment about the signed/unsigned
>svn_filesize_t. Maybe you missed it?
>
>You defined svn_filesize_t as unsigned. Per my comments in the issue, I
>think it should be signed.
>
>
Per my comments in the reply I wrote before reading this post of yours
(how's that for a preemptive defense?), I think it should be signed,
too, but that opens a whole can of worms.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Mar 18, 2003 at 11:35:54PM +0100, Branko Cibej wrote:
> Greg Stein wrote:
> >On Tue, Mar 18, 2003 at 01:24:51PM -0600, cmpilato@collab.net wrote:
> >
> >>+1, almost. Would rather do DATE->TXN_ID (that way we can get both
> >>committed and uncommitted transactions).
> >
> >As long as you have a way to go from TXN_ID to revnum(?).
>
> Oh, yes. For a committed txn, that's no problem. For an uncommitted one,
> only Buddha can find the revnum. :-)
Heh :-)
> >I don't see a need to *find* a transaction by date. I can see wanting to
> >sort the transactions, but I think it would be fine to get the list of txns
> >and then sort the results.
>
> Perhaps not today, but very probably someday. Dunno...
I'm not seeing it. txns are very transient in typical SVN usage. If you
drive the FS directly, then you can create long-lived txns. But the use
cases for finding by date? Still dunno there; that just doesn't feel like an
appropriate use case. *shrug*
> >If DATE->REVNUM is more efficient, then +1 on that, and -0 on DATE->TXN_ID.
>
> How about DATE->(TXN_ID [REVNUM])? Two stones with one bird. :-)
Well, we have at least one issue here:
DATE->TXN_ID imples the txn is still open, thus you inserted this "early"
DATE->(anything with revnum) implies a commit occurred
Note the difference in date values. If you put TXN_ID in there, then you're
going to do:
1. insert DATE->(TXN_ID )
2. time passes. txn changes. commit occurs.
3. remove DATE->(TXN_ID )
4. insert COMMIT_DATE->(TXN_ID REVNUM)
Personally, since I can't see a strong use case for DATE->TXN_ID, then I'd
suggest that we bail on that altogether. That means we only have step (4)
above.
At some point in the future, we can always start to insert mappings for open
transactions, and it would be very easy to detect that change in the skel.
> >So I'll make you a trade. I'll remove the prop if you add the table :-)
>
> Oooh, let me, let me! I haven't done any real work in the FS for ages,
> and it would be so nice to remember the grand old days again.
Heh. You and Mike can battle this out if we want to do it.
(I'm certainly +1 on it; just not sure what the overall consensus
for/against this change is)
> Right after I put in the svn_filesize_t change.
You haven't responded to my comment about the signed/unsigned
svn_filesize_t. Maybe you missed it?
You defined svn_filesize_t as unsigned. Per my comments in the issue, I
think it should be signed.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>On Tue, Mar 18, 2003 at 01:24:51PM -0600, cmpilato@collab.net wrote:
>
>
>>+1, almost. Would rather do DATE->TXN_ID (that way we can get both
>>committed and uncommitted transactions).
>>
>>
>
>As long as you have a way to go from TXN_ID to revnum(?).
>
Oh, yes. For a committed txn, that's no problem. For an uncommitted one,
only Buddha can find the revnum. :-)
[snip]
>I don't see a need to *find* a transaction by date. I can see wanting to
>sort the transactions, but I think it would be fine to get the list of txns
>and then sort the results.
>
Perhaps not today, but very probably someday. Dunno...
>If DATE->REVNUM is more efficient, then +1 on that, and -0 on DATE->TXN_ID.
>
How about DATE->(TXN_ID [REVNUM])? Two stones with one bird. :-)
>So I'll make you a trade. I'll remove the prop if you add the table :-)
>
Oooh, let me, let me! I haven't done any real work in the FS for ages,
and it would be so nice to remember the grand old days again. Right
after I put in the svn_filesize_t change.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Mar 18, 2003 at 01:24:51PM -0600, cmpilato@collab.net wrote:
>...
> > Greg Stein wrote:
> > >* is there a future scenario where revisions do not need to be time-ordered,
> > > so maybe this points to a flow in the current implementation?
> >
> > <whimsical-mode>Points to a flow...hmmm...and flows to a point,
> > too...<whimsical-mode>
"flaw flaw flaw flaw..." That was a flawed "flaw" .... :-)
> > As far as I know, there is exactly one reason why our commits must be
> > time-ordered: So that get_revision_by_date can do a binary search on
> > revision numbers. If we added an extra date->revision index, this
> > ordering wouldn't be necessary any more and we wouldn't need
> > svn:original-date.
Right. And I'm alright with that. I don't know how to get that done, yet I
*do* know how to add a property :-)
> > I'd rather introduce this index and lift the restriction on svn:date
> > than add another date property.
Totally cool with me.
> +1, almost. Would rather do DATE->TXN_ID (that way we can get both
> committed and uncommitted transactions).
As long as you have a way to go from TXN_ID to revnum(?).
> We can do so in a backwards-compatible fashion, too.
> svn_fs_create_berkeley will create and populate this table.
> svn_fs_open_berkeley will not.
So a dump/load would get the thing populated. Thus, it might be nice to do
this before the schema changes which require a dump/load? Thus, anybody who
upgrades will get the table?
> Then, we make a new public FS call,
>
> svn_error_t *svn_fs_dated_revision (svn_revnum_t *rev,
> svn_fs_t *fs,
> apr_time_t tm,
> int direction,
> apr_pool_t *pool);
>
> (where direction is used to determine which way to search for a
> revision when TM falls between two of them.)
I'm all for doing this, rather than the logic in repos. That's a bit
"expensive" to do it at that layer.
> This function can use cursors to find the closest transaction in the
> transaction table that is of type "committed".
Sure. Also need to define behavior for Brane's "multiple txn's at the same
date" issue. Maybe the direction is an enum:
enum {
svn_fs_rev_older, /* pick the revision older than the date */
svn_fs_rev_younger, /* pick the revision younger than the date */
svn_fs_rev_exact, /* only if a single revision matches; otherwise, bail */
svn_fs_rev_older_choose, /* choose one arbitrarily if multiple match */
svn_fs_rev_younger_choose, /* choose one arbitrarily if multiple match */
svn_fs_rev_choose /* choose one arbitrarily if multiple match */
}
(or a tri-state mode with a "choose" flag to 'or' into the mode)
>...
> Later, if we need
> svn_fs_dated_transaction, it does the same thing, but looks for
> "transaction"-typed transaction instead.
Sure.
> The function also returns
> SVN_ERR_UNSUPPORTED_FEATURE if the new table doesn't exist.
>
> svn_repos_dated_revision() can try svn_fs_dated_revision, and then
> fall back to its current brute-force method if
> SVN_ERR_UNSUPPORTED_FEATURE is returned.
Nah. Put the fallback into the FS code *until* we have a forced dump/load
cycle. After the dump/load the table will be there, so the compat code can
be removed. By shifting the code from repos to FS, then we can localize the
workaround code within the FS.
> NOTE: If, however, we don't think we'll ever need the perfect sorting
> of all transactions (including committed ones), ignore some of this
> and just do DATE->REVNUM -- that'd be more efficient.
I don't see a need to *find* a transaction by date. I can see wanting to
sort the transactions, but I think it would be fine to get the list of txns
and then sort the results.
If DATE->REVNUM is more efficient, then +1 on that, and -0 on DATE->TXN_ID.
So I'll make you a trade. I'll remove the prop if you add the table :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Working Copy Corruption
Posted by Joerg Hessdoerfer <Jo...@sea-gmbh.com>.
Hi,
On Tuesday 18 March 2003 21:13, D.J. Heap wrote:
[...]
>
> c:\Temp>svn up MoveTest
> svn: The system cannot find the file specified.
> svn: svn_io_copy_file: error copying
> 'MoveTest/.svn/text-base/blah.txt.svn-base' to
> 'MoveTest/.svn/tmp/text-base/blah.txt.svn-base.tmp'
>
>
> Or, more specifically, the .svn administrative directory of the parent
> directory has been hammered.
>
> Can anyone else reproduce this?
>
> Using Subversion 0.19.0 on WinXP.
>
Yep, I saw something quite similar, but can't exactly remember the steps which
led to the problem. In my case, I think i 'svn mv'ed a file in the WC, (and,
I think but am not sure, committed the state) and moved it back - same error
message.
Greetings,
Joerg
--
Leading SW developer - S.E.A GmbH
Mail: joerg.hessdoerfer@sea-gmbh.com
WWW: http://www.sea-gmbh.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Working Copy Corruption
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
I searched for an existing issue, but did not see one -- updating a
subdirectory with the -N (no recurse) option seems to corrupt the parent
directory. The repository seems fine.
Steps to repro:
c:\Temp>svn co file://localhost/c:/apps/svn_repos/fti/MoveTest
A MoveTest/test
A MoveTest/test/blah.txt
A MoveTest/stdafx.h
A MoveTest/MoveTest.cpp
A MoveTest/MoveTest.vcproj
A MoveTest/stdafx.cpp
A MoveTest/ReadMe.txt
Checked out revision 3.
c:\Temp>svn up MoveTest/test -N
At revision 3.
The parent directory now seems to be hammered although the command has
executed without error messages...
c:\Temp>svn st MoveTest
? MoveTest/MoveTest.cpp
? MoveTest/MoveTest.vcproj
? MoveTest/ReadMe.txt
! MoveTest/blah.txt
? MoveTest/stdafx.cpp
? MoveTest/stdafx.h
? MoveTest/test
c:\Temp>svn up MoveTest
svn: The system cannot find the file specified.
svn: svn_io_copy_file: error copying
'MoveTest/.svn/text-base/blah.txt.svn-base' to
'MoveTest/.svn/tmp/text-base/blah.txt.svn-base.tmp'
Or, more specifically, the .svn administrative directory of the parent
directory has been hammered.
Can anyone else reproduce this?
Using Subversion 0.19.0 on WinXP.
Thanks!
DJ
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:
>=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
>
>
>>I'd rather introduce this index and lift the restriction on svn:date
>>than add another date property.
>>
>>
>
>+1, almost. Would rather do DATE->TXN_ID (that way we can get both
>committed and uncommitted transactions).
>
>We can do so in a backwards-compatible fashion, too.
>svn_fs_create_berkeley will create and populate this table.
>svn_fs_open_berkeley will not. Then, we make a new public FS call,
>
> svn_error_t *svn_fs_dated_revision (svn_revnum_t *rev,
> svn_fs_t *fs,
> apr_time_t tm,
> int direction,
> apr_pool_t *pool);
>
>(where direction is used to determine which way to search for a
>revision when TM falls between two of them.)
>
Or when several txns have the same time. That can happen.
>This function can use cursors to find the closest transaction in the
>transaction table that is of type "committed". Later, if we need
>svn_fs_dated_transaction, it does the same thing, but looks for
>"transaction"-typed transaction instead. The function also returns
>SVN_ERR_UNSUPPORTED_FEATURE if the new table doesn't exist.
>
>svn_repos_dated_revision() can try svn_fs_dated_revision, and then
>fall back to its current brute-force method if
>SVN_ERR_UNSUPPORTED_FEATURE is returned.
>
Sounds like a plan.
>NOTE: If, however, we don't think we'll ever need the perfect sorting
>of all transactions (including committed ones), ignore some of this
>and just do DATE->REVNUM -- that'd be more efficient.
>
>
I don't think this would be a real efficiency problem, and I like the
flexibility of the date->txn index better (think about new txn types for
distributed repository synchronization, microbranches for changesets and
similar esoteric stuff that'll hopefully become quite mundane by 2.0).
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by cm...@collab.net.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> Greg Stein wrote:
>
> >* is there a future scenario where revisions do not need to be time-ordered,
> > so maybe this points to a flow in the current implementation?
> >
> >
>
> <whimsical-mode>Points to a flow...hmmm...and flows to a point,
> too...<whimsical-mode>
>
> As far as I know, there is exactly one reason why our commits must be
> time-ordered: So that get_revision_by_date can do a binary search on
> revision numbers. If we added an extra date->revision index, this
> ordering wouldn't be necessary any more and we wouldn't need
> svn:original-date.
>
> I'd rather introduce this index and lift the restriction on svn:date
> than add another date property.
+1, almost. Would rather do DATE->TXN_ID (that way we can get both
committed and uncommitted transactions).
We can do so in a backwards-compatible fashion, too.
svn_fs_create_berkeley will create and populate this table.
svn_fs_open_berkeley will not. Then, we make a new public FS call,
svn_error_t *svn_fs_dated_revision (svn_revnum_t *rev,
svn_fs_t *fs,
apr_time_t tm,
int direction,
apr_pool_t *pool);
(where direction is used to determine which way to search for a
revision when TM falls between two of them.)
This function can use cursors to find the closest transaction in the
transaction table that is of type "committed". Later, if we need
svn_fs_dated_transaction, it does the same thing, but looks for
"transaction"-typed transaction instead. The function also returns
SVN_ERR_UNSUPPORTED_FEATURE if the new table doesn't exist.
svn_repos_dated_revision() can try svn_fs_dated_revision, and then
fall back to its current brute-force method if
SVN_ERR_UNSUPPORTED_FEATURE is returned.
NOTE: If, however, we don't think we'll ever need the perfect sorting
of all transactions (including committed ones), ignore some of this
and just do DATE->REVNUM -- that'd be more efficient.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: Tuesday, March 18, 2003 6:45 PM
>>
>>
>
>
>
>>Greg Stein wrote:
>>
>>
>>
>>>* is there a future scenario where revisions do not need to be time-ordered,
>>> so maybe this points to a flow in the current implementation?
>>>
>>>
>>>
>>>
>><whimsical-mode>Points to a flow...hmmm...and flows to a point,
>>too...<whimsical-mode>
>>
>>As far as I know, there is exactly one reason why our commits must be
>>time-ordered: So that get_revision_by_date can do a binary search on
>>revision numbers. If we added an extra date->revision index, this
>>ordering wouldn't be necessary any more and we wouldn't need
>>svn:original-date.
>>
>>I'd rather introduce this index and lift the restriction on svn:date
>>than add another date property.
>>
>>
>
>Oh, +1. This also takes care of weird events like clocks being a day
>backwards on a server (which still seems to happen to some people sometimes):
>
> day T rev R
> day T-1 rev R+1
>
>Am I correct that get_revision_by_date won't find the R+1 when searching
>for T-1?
>
>
Right now, it won't.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn:original-date
Posted by Sander Striker <st...@apache.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Tuesday, March 18, 2003 6:45 PM
> Greg Stein wrote:
>
> >* is there a future scenario where revisions do not need to be time-ordered,
> > so maybe this points to a flow in the current implementation?
> >
> >
>
> <whimsical-mode>Points to a flow...hmmm...and flows to a point,
> too...<whimsical-mode>
>
> As far as I know, there is exactly one reason why our commits must be
> time-ordered: So that get_revision_by_date can do a binary search on
> revision numbers. If we added an extra date->revision index, this
> ordering wouldn't be necessary any more and we wouldn't need
> svn:original-date.
>
> I'd rather introduce this index and lift the restriction on svn:date
> than add another date property.
Oh, +1. This also takes care of weird events like clocks being a day
backwards on a server (which still seems to happen to some people sometimes):
day T rev R
day T-1 rev R+1
Am I correct that get_revision_by_date won't find the R+1 when searching
for T-1?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:original-date
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>* is there a future scenario where revisions do not need to be time-ordered,
> so maybe this points to a flow in the current implementation?
>
>
<whimsical-mode>Points to a flow...hmmm...and flows to a point,
too...<whimsical-mode>
As far as I know, there is exactly one reason why our commits must be
time-ordered: So that get_revision_by_date can do a binary search on
revision numbers. If we added an extra date->revision index, this
ordering wouldn't be necessary any more and we wouldn't need
svn:original-date.
I'd rather introduce this index and lift the restriction on svn:date
than add another date property.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org