Matthieu Moy <[EMAIL PROTECTED]> writes:
> Stephen Leake <[EMAIL PROTECTED]> writes:
>
>> Matthieu Moy <[EMAIL PROTECTED]> writes:
>>
>>> About previous-revision, the problem is that to view the diff
>>> introduced by a revision, some back-ends force you to write
>>>
>>> $ DVC -r direct-ancestor..revision
>>>
>>> or such thing. So, what DVC does, when you press "=" on a revision in
>>> a revision list buffer is that it shows the diff between the revision
>>> you're on and its ancestor.
>>>
>>> In git, (previous-revision X) is just X^.
>>
>> Hmm. In monotone, there is no such thing as "a revision of a file";
>> each "revision" is a set of changes to a set of files; it may just be
>> one file, it may be more.
>
> Sure, like any other modern VCS I know (git, hg, bzr, even GNU Arch
> and svn). "X", in my example, was a revision, not a file.
Ok, good.
I was playing with DVC diff-mode operations, and it seemed like some
operations where trying to find the previous revision of a _file_, in
order to use ediff to view the changes; I'll have to look again.
Perhaps they were trying to find "the state of the file on this branch
before this revision". That's better defined.
>> One thing I expected to find in DVC was more support for this notion.
>
> That's definitely one of the goal.
Good.
>> For example, when preparing to commit changes, I would like to see the
>> possibility of assigning changes to different files to different
>> revisions, and collecting comments on each revision separately. That's
>> how I work; I edit whatever file seems to need editing, even though
>> "logically" the edits are for different purposes. Being able to define
>> what revision each change is part of would make that clearer.
>
> Well, in this case, you have to do several commits, so what's wrong
> with
>
> while (changes) {
> M-x dvc-status RET
> (select files to commit)
> 'c'
> (edit log)
> C-c C-c
> }
As I mention below, this means I have to consider some files more than
once, which is inefficient.
>> Until I hit a file that has two independent changes that belong in
>> separate revisions, I suppose. That's an argument for committing more
>> often. Which is easier when it doesn't require a (slow) network
>> connection.
>
> That's also an argument to have partial revert/reapply tools.
>
> <examples of tools snipped>
>
> In DVC, there's nothing for that purpose up to now.
Nice to hear other people have this problem :).
I think the potential for confusion, and as you point out, untested
combinations of changes, outweighs whatever convenience this might
offer.
>> I can approximate this now by marking the files involved in one
>> revision, committing that, then marking another set, etc. That
>> requires several passes thru the status buffer display, which is
>> inefficient; I'd prefer to think about each file only once, in the
>> order they happen to be displayed.
>
> In any case, you'll have to do multiple commits, and test your project
> before you commit. If you're not too strict, "test" can mean just
> "check whether it compiles", but it's sooooo easy to change foo.h to
> add a function, bar.c to use it, and then to commit only bar.c
> (remember, the CVS old good time, hey!)
I use my CM tool more casually than that; I don't mind checking in
things that don't compile, as long as they don't stay that way very
long. I check in when I feel I need a backup/checkpoint.
If I'm making a big change, so the code won't compile for a while, I
make a branch.
As a team gets larger, the need for branching occurs more often,
because it's more important that the main branch compile.
So "test before commit" is not a requirement.
It would be interesting to do a survey of how people view changesets;
are they always coherent changes, or are they just what happens to
have changed at the time?
>> If other backends still directly support (or require) the notion of
>> "revision history of one file", it will be a major conflict for the
>> DVC front-end.
>
> What most of them have is a feature to view the history, filtered by a
> file or a set of files.
>
> For example,
>
> $ bzr log file.c
>
> will show you the subset of
>
> $ bzr log
>
> touching file "file.c". But that's mostly a user-interface thing, the
> model behind is still atomic commits.
Ok. It would be good for this operation to be in the DVC front-end. I
haven't looked to see if it is.
> DVC can show you a similar interface, but can not _unify_ back-ends
> with so different underlying model. Take the file-ID thing above:
> that's a non-problem for git, who has a totally different model to
> manage renames. The user will know one day or another what back-end is
> used.
Right. DVC can only unify the greatest common subset of operations.
>> To me, that genericity layer looks like a consistent common front-end
>> to several backends. But maybe that's just my vision.
>
> The main reason for its existance it to have a single menu and set of
> keybindings for all back-ends.
>
> For example, I can type C-x V L in any tree, I'll get the log. But the
> log will be formated in a "tla" fashion if I'm within a tla tree, and
> in a bzr fashion if I'm in a bzr tree.
>
> What's hardcoded in my fingers works regardless of the back-end, but
> Emacs doesn't hide it from me.
Right. That's what I'm looking for.
--
-- Stephe
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
