Stefan Reichör | 1 Oct 07:34
Picon

[commit] rev 269: Merged from Michael Olson: xgit-annotate improvements

Committed revision 269 to http://bzr.xsteve.at/dvc/

Merged from Michael Olson: xgit-annotate improvements
    ------------------------------------------------------------
    revno: 241.1.37
    committer: Michael W. Olson <mwolson <at> gnu.org>
    branch nick: mwolson
    timestamp: Sat 2007-09-29 23:36:55 -0400
    message:
      xgit-log: Fix typo in docstring

      * lisp/xgit-log.el (xgit-log): Fix typo in docstring,
    ------------------------------------------------------------
    revno: 241.1.36
    committer: Michael W. Olson <mwolson <at> gnu.org>
    branch nick: mwolson
    timestamp: Sat 2007-09-29 23:06:57 -0400
    message:
      xgit-annotate: Fix several edge cases

      * lisp/xgit-annotate.el (xgit-annotate-info-regexp): Take into account
        the fact that git may display the filename next to the SHA1 hash, if
        the current line originated from a different file.
        (xgit-annotate-get-rev): Don't use re-search-backward.  Not only is it
        slow, but it is unnecessary, since we want to match from the beginning
        of the line anyway.
        (_xgit-annotate-hide-revinfo): Do not go back one line if we are at the
        end of the buffer, otherwise we'll get into an infinite loop.
    ------------------------------------------------------------
    revno: 241.1.35
(Continue reading)

Matthieu Moy | 1 Oct 15:02
Picon
Picon
Favicon

Re: dvc-add-log-entry vs dvc-partner-buffer

Stephen Leake <stephen_leake <at> stephe-leake.org> writes:

>>> Solution 0 also works for me.
>>
>> It doesn't change your problem.
>>
>> M-x dvc-status RET
>> mark files

Add

c (to create a log buffer)
go back to dvc-status

...

>> RET (to open a file)
>> C-x V a
>> C-c C-c
>
> In solution 0, C-x V a would abort, because there is not yet a
> log-edit buffer, and it doesn't know how to create it properly.

And it wouldn't abort.

And you'll get a full commit, even with files marked in the status
buffer (I've just checked, with your latest commit in, at least with
git backend).

I still think that your solution doesn't solve the problem.
(Continue reading)

Matthieu Moy | 1 Oct 15:12
Picon
Picon
Favicon

Re: rev 258: In dvc-add-log-entry, avoid setting dvc-partner-buffer wrong, and avoid using wrong back-end.

[ side note: do we have an easy way to get the corresponding diff for
  such notification messages? I'm bzr diff-ing manually, but it would
  be nice to have it automatized, as we used to have for Xtla ].

Let's be constructive, I'll stop arguing against the rational for this
patch, but some points need to be fixed:

Stephen Leake <stephen_leake <at> stephe-leake.org> writes:

> Committed revision 258 to http://stephe-leake.org/dvc

> === modified file 'lisp/dvc-buffers.el'
> --- lisp/dvc-buffers.el 2007-09-20 18:49:38 +0000
> +++ lisp/dvc-buffers.el 2007-09-26 11:21:32 +0000
> @@ -183,6 +183,18 @@
>                   return-buffer dvc default-directory)
>        return-buffer)))
>  
> +(defun dvc-type-buffers (type)
> +  "Return the list of all buffers of type TYPE."
> +  (let ((result nil)
> +        (tree dvc-buffers-tree))
> +    (while tree
> +      (let ((entries (cdr (assoc type (car tree)))))
> +        (while entries
> +          (setq result (cons (nth 1 (car entries)) result))
> +          (setq entries (cdr entries))))
> +      (setq tree (cdr tree)))
> +    result))
> +
(Continue reading)

Stephen Leake | 2 Oct 12:25
Favicon

Re: dvc-add-log-entry vs dvc-partner-buffer

Matthieu Moy <Matthieu.Moy <at> imag.fr> writes:

> Stephen Leake <stephen_leake <at> stephe-leake.org> writes:
>
>>>> Solution 0 also works for me.
>>>
>>> It doesn't change your problem.
>>>
>>> M-x dvc-status RET
>>> mark files
>
> Add
>
> c (to create a log buffer)
> go back to dvc-status
>
> ...
>
>>> RET (to open a file)
>>> C-x V a
>>> C-c C-c
>>
>> In solution 0, C-x V a would abort, because there is not yet a
>> log-edit buffer, and it doesn't know how to create it properly.
>
> And it wouldn't abort.

Yes, that is the usage with solution 0.

> And you'll get a full commit, even with files marked in the status
(Continue reading)

Stephen Leake | 2 Oct 13:34
Favicon

Re: rev 258: In dvc-add-log-entry, avoid setting dvc-partner-buffer wrong, and avoid using wrong back-end.

Matthieu Moy <Matthieu.Moy <at> imag.fr> writes:

> [ side note: do we have an easy way to get the corresponding diff for
>   such notification messages? I'm bzr diff-ing manually, but it would
>   be nice to have it automatized, as we used to have for Xtla ].

Ah; a keystroke in Gnus that would bring up a dvc-diff buffer for the
commit in the current email. It could prompt for the root directory.

I do that by pulling, updating, and then diffing. 

> Let's be constructive, I'll stop arguing against the rational for this
> patch, but some points need to be fixed:
>
> Stephen Leake <stephen_leake <at> stephe-leake.org> writes:
>
>> Committed revision 258 to http://stephe-leake.org/dvc
>
>> === modified file 'lisp/dvc-buffers.el'
>> --- lisp/dvc-buffers.el 2007-09-20 18:49:38 +0000
>> +++ lisp/dvc-buffers.el 2007-09-26 11:21:32 +0000
>> @@ -183,6 +183,18 @@
>>                   return-buffer dvc default-directory)
>>        return-buffer)))
>>  
>> +(defun dvc-type-buffers (type)
>> +  "Return the list of all buffers of type TYPE."
>> +  (let ((result nil)
>> +        (tree dvc-buffers-tree))
>> +    (while tree
(Continue reading)

Matthieu Moy | 2 Oct 14:18
Picon
Picon
Favicon

Re: rev 258: In dvc-add-log-entry, avoid setting dvc-partner-buffer wrong, and avoid using wrong back-end.

Stephen Leake <stephen_leake <at> stephe-leake.org> writes:

>> That's not a really interesting thing to do: what you want here is to
>> find all buffers of type TYPE, for a given back-end, and for a given
>> tree root.
>
> Yes, except we don't know the back-end. dvc-buffer-current-active-dvc
> is not set in source buffers, so we have to ignore back-end while
> searching, and get the back-end from the log-edit buffer.

The convention in DVC now is that the root is the first parent
directory being a local tree of a back-end registered in DVC.

The back-end in use is chosen according to dvc-select-priority.

So, currently, this situation ...

> Consider this use case:
>
> [...]
>
> But this user just wants one mtn database containing everything, while
> keeping the bzr databases separate.

is simply not managed.

This problem is unrelated from the issue we're talking about. If you
want your above setup to be managed correctly, you need a solution
that works for dvc-file-diff, dvc-file-ediff, dvc-diff,
dvc-status, ... well, just about everything in DVC.
(Continue reading)

Matthieu Moy | 2 Oct 14:32
Picon
Picon
Favicon

Re: dvc-add-log-entry vs dvc-partner-buffer

Stephen Leake <stephen_leake <at> stephe-leake.org> writes:

> Matthieu Moy <Matthieu.Moy <at> imag.fr> writes:
>
>> Stephen Leake <stephen_leake <at> stephe-leake.org> writes:
>>
>>>>> Solution 0 also works for me.
>>>>
>>>> It doesn't change your problem.
>>>>
>>>> M-x dvc-status RET
>>>> mark files
>>
>> Add
>>
>> c (to create a log buffer)
>> go back to dvc-status
>>
>> ...
>>
>>>> RET (to open a file)
>>>> C-x V a
>>>> C-c C-c
>>>
>>> In solution 0, C-x V a would abort, because there is not yet a
>>> log-edit buffer, and it doesn't know how to create it properly.
>>
>> And it wouldn't abort.
>
> Yes, that is the usage with solution 0.
(Continue reading)

Stephen Leake | 3 Oct 12:11
Favicon

Re: dvc-add-log-entry vs dvc-partner-buffer

Matthieu Moy <Matthieu.Moy <at> imag.fr> writes:

>> Yes, that is the usage with solution 0.
>>
>>> And you'll get a full commit, even with files marked in the status
>>> buffer (I've just checked, with your latest commit in, at least with
>>> git backend).
>>
>> Yes.
>
> So, what's the expected behavior for you?
>
> You have a problem with dvc-add-log-entry setting the partner buffer
> while creating the *log-edit* one, but you seem to have no problem
> setting it when reusing an existing buffer.

Hmm. dvc-partner-buffer should not change when the buffer is reused by
dvc-add-log-entry. 

But if dvc-add-log-entry calls dvc-log-edit, it is changed (I was
assuming it wasn't if the buffer was reused). So my patch is broken; I
guess I did not test very well :(.

So dvc-add-log-entry can't just call dvc-log-edit to reuse a buffer;
it has to switch to it only.

I was thinking of doing that anyway, because xmtn recomputes the
commit comment when you call dvc-log-edit, which is not appropriate
for dvc-add-log-entry.

(Continue reading)

Stephen Leake | 3 Oct 12:33
Favicon

Re: rev 258: In dvc-add-log-entry, avoid setting dvc-partner-buffer wrong, and avoid using wrong back-end.

Matthieu Moy <Matthieu.Moy <at> imag.fr> writes:

> Stephen Leake <stephen_leake <at> stephe-leake.org> writes:
>
>>> That's not a really interesting thing to do: what you want here is to
>>> find all buffers of type TYPE, for a given back-end, and for a given
>>> tree root.
>>
>> Yes, except we don't know the back-end. dvc-buffer-current-active-dvc
>> is not set in source buffers, so we have to ignore back-end while
>> searching, and get the back-end from the log-edit buffer.
>
> The convention in DVC now is that the root is the first parent
> directory being a local tree of a back-end registered in DVC.
>
> The back-end in use is chosen according to dvc-select-priority.

There is also dvc-temp-current-active-dvc, which is easier to use than
dvc-select-priority:

(let ((dvc-temp-current-active-dvc 'xmtn)) (dvc-status "/Gnu/dvc-fileinfo/"))
(let ((dvc-temp-current-active-dvc 'bzr))  (dvc-status "/Gnu/dvc-fileinfo/"))

If I am actively using two back-ends for the same workspace, it needs
to be easy to tell DVC which one to use for any given operation. The
current mechanisms are ok so far, but could be better.

>> Consider this use case:
>>
>> [...]
(Continue reading)

Matthieu Moy | 3 Oct 15:17
Picon
Picon
Favicon

Re: dvc-add-log-entry vs dvc-partner-buffer

Stephen Leake <stephen_leake <at> stephe-leake.org> writes:

> So dvc-add-log-entry can't just call dvc-log-edit to reuse a buffer;
> it has to switch to it only.

Probably it's better to have dvc-log-edit itself reuse the buffer
without setting the partner buffer, so that both log-edit and
add-log-entry benefit of the fix.

>>> Ah. That is a different solution. I don't think it's viable; consider
>>> the case of two parallel workspaces, each controlled by different
>>> back-ends with different repositories. You always commit them at the
>>> same time, and review them in parallel, in two status buffers. Thus
>>> there are two status buffers with marked files, and two log-edit
>>> buffers; which does the commit choose?
>>
>> If the buffers are in sync, you don't care which one to chose.
>
> Since they are commiting to different repositories, it does make a
> difference. 
>
> Suppose the workspace for project A is ready to commit, but B still
> has some files to review. You are in the log-edit buffer for A, and
> hit C-c C-c. But dvc-log-edit-done chooses the log-edit buffer for
                                                 ^^^^^^^^
I suppose you mean "status" here.

> B, and it does the wrong thing.

Then, your point is not that you can choose the wrong buffer, but that
(Continue reading)


Gmane