Evgeny Kotkov wrote on Wed, Mar 04, 2015 at 04:42:58 +0300:
> Bert Huijben <bert_at_qqmail.nl> writes:
>
> >> Don't expose internal transaction properties like 'svn:check-locks' through
> >> the public FS API and error out on attempts to change them.
> >
> > I wish it would be possible to put these in their own property namespace,
> > to avoid those list of properties to check against...
> >
> > But that is not really possible any more, is it?
>
> I am afraid it is not possible for the reasons Philip has already mentioned.
> As long as we use these properties in the on-disk format, we cannot alter
> their names without breaking compatibility.
>
Those names are private APIs. We have to support existing transactions
written to disk with the existing property names. That means we _can_
rename the properties, so long as svn_fs_open_txn() looks for the
properties under their old name too (and, let's say, converts the
properties to the new name before returning).
There are some complications here, such as ensuring the old
and new names are never both set on the same transaction, but it's
a manageable exercise, if we wanted to do it for some reason.
(Or maybe we make 'svnadmin upgrade' rename the properties from their
legacy non-namespaced names to their new namespaced names.)
> Unfortunately, I am unaware of a solution that would allow us to stop checking
> these properties against a predefined list of names. Even with theoretically
> possible options like using a special namespace in the newer filesystem formats
> or making these filesystems use something else than a set of temporary props
> for the transaction flags, we'd still require this check somewhere in order to
> be backward compatible.
We can't stop checking for the old names in persisted-to-disk
transactions, but we can introduce a namespace for all future (and
not-yet-released) names. That will simplify our code from:
1. Unset property A
2. Unset property B
3. Unset property C
/* Hopefully remember to add property D here, if it's ever defined */
to:
1. Unset property A
2. Unset property B
3. Unset all properties in the svn:txn-* namespace
The benefit of the latter is that it prevents the "forgetting to update
the list of exceptions when defining a new txnprop" kind of bug.
Cheers,
Daniel
Received on 2015-03-04 03:13:46 CET