[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Specifying commit timestamps over RA

From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 27 Nov 2013 23:06:54 +0100

> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> Sent: woensdag 27 november 2013 21:20
> To: Philip Martin
> Cc: dev_at_subversion.apache.org
> Subject: Re: Specifying commit timestamps over RA
> Philip Martin wrote on Wed, Nov 27, 2013 at 18:57:13 +0000:
> > In 1.9 we have a new API svn_fs_commit_txn2 that allows 'svnadmin load'
> > to create a revision with a specified timestamp rather than having to
> > make a commit with the "wrong" date followed by a revision property
> > change to set svn:date to the correct value. WANdisco are interested in
> > making this feature available over RA so that it can be used for
> > replication. svnsync could use such an implementation to avoid having
> > to make an svn:date revision property change after each commit.
> >
> The intention here being to speed up sync of histories containing many
> small commits, I presume. Okay.
> > We already have the code to transfer a revision property over the
> > network and set it on a transaction (the client traps attempts to set
> > svn:date but otherwise it works). Currently attempts to set svn:date
> > are silently ignored by the server. This would remain the default
> > behaviour unless the administrator enables the new feature, probably
> > controlled by a setting in the Apache config file and svnserve.conf.
> >
> So we would have a config file setting which allows users to bypass the
> pre-revprop-change hook? Perhaps the "temporary property" (the property
> which tells the FS layer not to overwrite svn:date) should instead be
> set by the pre-commit hook?
> That would be:
> 1. When user sets svn:date on a commit, the RA layer just sets svn:date
> in the props hash, like is done with every other property.
> 2. In the FS, where today svn:date is being overridden, only do that if
> the "temporary property" you mentioned is set. The temporary property
> is always removed during commit, just like
> 3. The temporary property must be impossible to over the wire.
> > I see it working like this: the server advertises that the feature is
> > available, [...]
> How about just teaching the server to always send the svn:date property
> along with the "Commit was successful, its revnum is N" response? (for
> all commits)
> This doesn't even require a new capability; the client can just notice
> the extra field if it's there, and issue a propset if it's absent. (It
> could issue a propget as well, but in the svnsync case there is no
> reason to.)

As far as I know it already does this. The client already updates the last_*
values based on the information we get from the server. (And that is what
you get back as the commit info)

And perhaps we can use the new in 1.8 'EPHEMERAL txn' properties for some of
the client to server communication.

Received on 2013-11-27 23:07:38 CET

This is an archived mail posted to the Subversion Dev mailing list.