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

Re: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 27 Nov 2015 12:45:57 +0000

"Bert Huijben" <bert_at_qqmail.nl> writes:

> Another option would be to just store the revision number in the
> string representation of the txn-id and keep the on-disk behavior the
> same as it is today. Can we just add an (optional) component there?

I suppose that would work. It might break any third-party code that
parses BDB txn-ids. There probably isn't any such code for BDB but I am
aware of a comparable issue in some 3rd party FSFS code

> Any fix that would make us load the txn back the way it was before
> serializing it would be a good fix for me.
> I would also be +0 on a fix that makes the base rev lower directly on
> creating the txn. (I'll fix mod_dav in that case)

I think that is the wrong solution. Our public API passes a base
revision to svn_fs_begin_txn() and I think it would be odd if
svn_fs_txn_base_revision() did not return the same revision. I think
that is preserving the behaviour that is most likely to break 3rd party

I prefer the solution that makes the root path mutable before commit so
that the revision has a distinct root node-revision-id.

Philip Martin
Received on 2015-11-27 13:46:15 CET

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