Matthieu Moy, 2007-04-16:
> Christian Ohler <[EMAIL PROTECTED]> writes:
>
>> Right, I'm familiar with revision _IDs_. Sorry if this wasn't clear
>> from my message. The docstring refers to revision _specifiers_,
>> though, which are a different beast, and bzr-specific.
>
> I'm not describing revision _ID_. A revision ID is a unique
> identifier. That is: one revision ID corresponds to one revision, and
> one revision has only one ID. Depending on the system you use,
> revision ID are semi-random string (bzr), hash-sum (git, monotone), or
> namespace-based (GNU Arch).
The file docs/DVC-API defines the term "revision identifier" as follows:
> We define a unified way to designate a revision in lisp,
> which we call revision identifiers, or rev-id:
>
> REVISION-ID :: (<dvc> BACK-END-ID)
> ;; <dvc> is one of 'tla, 'bzr, 'xhg, ...
The code uses similar naming. This is consistent with my use of the
term "revision ID", but not with yours (unless you want to say that
"revision identifier" and "REVISION-ID" are really the same as "revision
specifier", while "revision ID" is something entirely different).
Let's either stick to the terminology in the documentation, or change
the documentation to reflect the terminology we want to use.
(I think your terminology is preferable. Also, some variables in xmtn
that hold 40-digit hex strings are named `revision-hash-id' instead of
the more appropriate `revision-id' because the term revision ID is
already taken in DVC. This is really clumsy and could be avoided with
the term "revision specifier". But switching the terms might just
create a similar dilemma for the bzr backend, and I don't want to search
and replace through the entire code right now.)
> Now, the _way_ you define revision specifiers depends on the back-end.
> I don't know at all about monotone, but I'm pretty sure you have a way
> to say "last revision I commited yesterday", or "direct ancestor of
> revision X".
In monotone's world, "direct ancestor of revision X" is *not* a way to
unambiguously specify a revision, because merges are frequent, and merge
revisions have two direct ancestors, not just one.
This makes DVC's (last-revision ...) and (previous-revision ...)
revision IDs problematic for xmtn. It would probably be desirable to
generalize revision IDs to make them more compatible with monotone, but
I don't think this is a pressing problem.
>> The usual model seems to be that "status" provides an overview of how
>> the version control system sees the workspace, and what it's going to
>> record when the user hits the commit button. In this model, computing
>> the status against an arbitrary revision is meaningless.
>
> Sure. That's 99% of cases, but it doesn't harm to be able to do the 1%
> remaining.
Actually, my description above was an attempt to give a reasonably
general description of what "status" might be defined to do in DVC,
_regardless_ of which backend is in use. All backends would implement
this; there would be no other 1%.
> And once more, "depending on the back-end", "diff" might not show
> changes in metadata (permissions, symlink change, ...). So, there are
> cases where "status" contains informations that "diff" does not.
If one of the backend revision control systems happens to provide a
command called "status" that is needed to show changes in metadata, we
shouldn't dilute DVC's notion of status to accommodate this backend
("the status command might be useful to prepare your commit, or maybe
its primary use is showing changes in metadata; it depends on your
backend"). We should rather have the backend's implementation of diff
also run the command called "status" and integrate its output, or add a
special "show changes in metadata" command to this backend.
But unless there is an actual backend with this property, I don't think
we should worry about this at all. Thinking about what the general case
might look like is important when there are only one or two backends,
but we have 6 now. This is enough data to base the design on.
>> None of the backends except tla seem to implement the AGAINST
>> argument; this also indicates that it can't be needed much. So,
>> instead of having a note "not implemented in this backend" in every
>> backend, let's just remove the argument.
>
> I'm not opposed to removing it, but I don't think it's really an
> improvement.
I'll go ahead, then. The AGAINST argument is unused cruft in the API,
removing it is a good thing.
Christian.
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
