Ivan Zhakov <i...@visualsvn.com> writes:
> While I added svn_fs_commit_txn2() function I think it should not be
> exposed through svn_repos_* and RA layer.
Is there a reason this was implemented as svn_fs_commit_txn2 rather than
as another flag passed to svn_fs_begin_txn2? They seem to be equivalent
but the flags mechanism was already present.
I'm also wondering whether the new behvaiour is what we want. In 1.8 we
have:
svn_fs_begin_txn2: set temporary date
svn_fs_change_txn_prop: optional change temporary date
svn_fs_commit_txn: overwrite temporary date
the current 1.9 is:
svn_fs_begin_txn2: set date that may be temporary
svn_fs_change_txn_prop: optional change date that may be temporary
svn_fs_commit_txn2: overwrite or keep date
If the caller doesn't do svn_fs_change_txn_prop then svn_fs_commit_txn2
can preserve the temporary date set by svn_fs_begin_txn2. Is that
useful?
The FS layer could track svn_fs_change_txn_prop changes to svn:date via
a temporary transaction property. Then we would know at commit time
whether the date has been explicitly set. When commit is asked not to
overwrite the date and the date has not been explicitly set we could
either overwrite anyway or fail the commit. Thus we would avoid making
the svn_fs_begin_txn2 date permanent.
> FS layer currently doesn't treat svn:date as special property except
> commit. And for commit operation it just an option add timestamp
> within lock to guarantee them strictly ordered. As far I remember
The system clock can be adjusted. We would need to explicitly compare
the proposed new revision with the previous HEAD to get a guarantee.
> Michael C. Pilato said somewhere that this intentional FS layer
> design.
>
> Repos layer is different: it relies on svn:date order in functions
> like svn_repos_dated_revision(). Repos layer has functions to load
> repository dump, but this dump supposed to be created by
> svn_repos_dump_fs() and have valid svn:date order. Adding option to
> specify custom svn:date for new revision in svn_repos() layer will
> break this invariant.
We have to accept that revisions may not be in svn:date order and that
some revisions may not have an svn:date.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
