Greg Hudson's comments echo mine, so I won't repeat those here.
Just a few other questions, though:
Branko Čibej <brane@xbc.nu> writes:
> 3.1 DB schema changes
>
> The filesystem grows a new table, "revpropindex", with the following schema:
>
> (PROP-NAME PROP-VALUE) -> REVNUM
>
> Non-unique indexes are allowed.
Is there a reason not to do non-uniqueness like this:
(PROP-NAME PROP-VALUE) -> (REVNUM1, REVNUM2, REVNUM1 ...)
and retain unique indexes?
> No other changes are necessary. For forward compatibility, servers that
> do not implement revision indexes will ignore this table; for backward
> compatibility, if the table does not exist in the repository, revision
> indexing and search operations are disabled. The dumpfile format does
> not change, as the contents of the revision index can be reconstructed
> from revprop data.
If the feature is allowed to be unavailable anyway, then I'd prefer
not to have the special rule that "svn:date" and "svn:name" are always
indexed. Why not let them be controlled in the same way as everything
else?
> 3.2 Multiple indexes per revision
>
> The values of properties that allow multiple keys per single revision
> are represented in a newline-terminated list, one value per line (like
> the svn:ignore property on directories). Each value is added as a
> separate key to the index.
I didn't understand this, sorry. Can you maybe give an example, or
try saying it another way? (Probably this is somehow related to my
earlier question about unique indexes.)
> 3.3 Indexing configuration
>
> The repository grows a new configuration file, conf/revpropindex. The
> format of the file is as follows:
>
> [propname]
> unique = [TRUE/false]
> multiple = [FALSE/true]
>
> Revprops that do not appear in the config file are not indexed. The
> default contents of this file are:
>
> [svn:date]
> unique = false
> multiple = false
> [svn:name]
> unique = false
> multiple = true
>
> The svn:date and svn:name indexing cannot be turned off, neither can the
> indexing parameters change (in effect, we may as well not actually
> enable these in the revpropindex config file).
(See earlier comments about forced indexing.)
> 3.4 FS/Repos API changes
>
> When opening an existing repository, the FS layer must not error out if
> the revpropindex table does not exist.
>
> The repos layer grows a new function,
>
> svn_repos_revision_search(propname, propvalue)
>
> which returns a list of revision numbers. The list can be empty. No
> error is returned if a property is not indexed or revision indexing is
> not enabled in the repository (i.e., if the repository schema version is
> older than the server version).
Why is it better to return an empty list than an
SVN_ERR_UNSUPPORTED_FEATURE error or something like that?
> The propset, propchange and propdel repos-level wrappers must maintain
> the revpropindex table (optimization hint: when changing multi-value
> properties, only values deleted from or added to the list need to be
> processed).
>
> The function svn_repos_dated_revision changes: first, it calls
> svn_repos_revision_search("svn:date", timestamp). If this returns a
> non-empty list, it returns the oldest revision from this list. Otherwise
> it performs the current binary search. (The binary-search implementation
> must stay for backward compatibility. It can be removed in 2.0.)
> svn_repos_committed_info and svn_repos_history get similar changes.
Ooooh. I have a feeling if I understood your earlier thing about
"properties that allow multiple keys per single revision", I'd
understand this part :-(.
> 4. Implementing revision names
>
> Using the mechanism described above, we can add symbolic names to a
> revision or a set of revisions. To do this we introduce a new revision
> property, "svn:name", that contains a newline-separated list of symbolic
> names assigned to a revision. The values are non-unique: that is, a
> single symbolic name can group several distinct revisions.
If we're calling these "labels", then let's use "svn:label".
> While the existing "prop(get|set|edit) --revprop" functionality is
> sufficient for setting and maintaining revision names, it is not really
> useful. I propose the following changes to the UI:
>
> 4.1 Extend the format of the "-r" command-line option
>
> Currently the -r command-line option accepts a revision number or a date
> (range):
>
> -r revnum|{date}[:revnum|{date}]
>
> The {date} specifier is internally converted to a revision number. We
> add another specifier, [labelname], that is also converted to a revision
> number.
This sounds great (exactly the way CVS does it too).
> Note: Since label values are non-unique, a [label] specifier can refer
> to a list of revision numbers. Such lists useless for "svn update" or
> "svn export"; however, "svn merge" could be extended to handle
> multi-revision merges (cherry-picking, right?). We should support an
> analogous format, "-r revnum,revnum,..." for specifying an explicit list
> of revision numbers; this is also needed for defining multi-revision labels.
Yes, and even before that's supported, we can have the [labelname]
expansion be comma-separated when multiple revisions come back. That
way the -r option will give a syntax error for the stuff it can't
handle yet.
> 4.2 svn label [-r revnum/range/list] label-name
>
> Adds a label to the specified revision(s). All forms of the -r option
> are supported (including label specifiers, of course). The default is to
> label HEAD.
>
> 4.3 svn labeldel [-r revnum/range/list] label-name
>
> Remove a label from the specified revision(s). If -r is not specified,
> remove all instances of the label.
I'm not quite as opposed as Greg Hudson to having new commands for
this, but would like to first do without and see whether or not it's a
problem for people. 'svn propset --revprop -rN svn:label VALUE' isn't
so hard, especially for an early adopter. It feels premature to add
dedicated subcommands for workflow-specific uses of properties, before
we've had a chance to see how often and in what way the properties
actually get used.
> All these functions need equivalents in the client library; the RA layer
> only has to expose svn_repos_revision_search. "svn label: and "svn
> labeldel" can be implemented as simple revprop manipulations, although
> implementing them on the server would make multi-revision labeling faster.
This optimization is independent of the command set, if we implement
the '-rN,M,...' syntax.
> 5. Future notes
>
> Currently no history is recorded about revprop changes. This is an
> oversight that makes Subversion behave slightly at cross-purposes with
> configuration management philosophy. Unfortunately, in order to record
> historical changes to revprops, a slightly more drastic change is needed
> not just to the schema and API, because these changes would have to be
> recorded in a new kind of transaction. Thus this kind of history
> tracking cannot be implemented before 2.0.
I agree, and wonder how high priority this should be.
Look at it this way: assume that *every* change is versioned in the
sense that
- it can be rolled back to any previous point
- it has some metadata (a log message) associated with it
...then a change to metadata itself must be rollbackable and have
associated metametadata. You can see how this begins to stack up.
It's not totally impossible to implement the infinite tower, it's just
a pain. Subversion has chosen to "bottom out" at the first level --
the metadata associated with a commit is not versioned, it's just
metadata. Is that at odds with CM philosophy, or is it more that if
one wants something versioned, one should put it under version
control?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 19 19:16:24 2004