bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Andrii Kolomoiets
Hi,

By invoking single 'summary' command we can get more info about
repository state: parent revisions, current branch, tags, bookmarks,
commit status, available updates and phase.


0001-vc-hg-use-hg-summary-to-populate-extra-vc-dir-header.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Dmitry Gutov
Hi Andrii,

On 26.11.2019 17:16, Andrii Kolomoiets wrote:

> By invoking single 'summary' command we can get more info about
> repository state: parent revisions, current branch, tags, bookmarks,
> commit status, available updates and phase.

I guess the questions are:

- Is this output better than the previous one? Hopefully others will
chime in, e.g. Daniel, who wrote some major improvements to vc-hg a few
years ago.

- Is 'hg summary' stable enough? Maybe a few years from now Mercurial
changes its output and this code stops working in all Emacs we'd have
released in the meantime? This is why we try to use "porcelain" level
commands (in Git terminology) when possible, not user-level.



Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Andreas Schwab-2
On Nov 27 2019, Dmitry Gutov wrote:

> - Is 'hg summary' stable enough? Maybe a few years from now Mercurial
> changes its output and this code stops working in all Emacs we'd have
> released in the meantime? This is why we try to use "porcelain" level
> commands (in Git terminology) when possible, not user-level.

Git calls them "plumbing".  "Porcelain" are the high-level commands.

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Dmitry Gutov
On 27.11.2019 15:37, Andreas Schwab wrote:
> Git calls them "plumbing".  "Porcelain" are the high-level commands.

My mistake, I guess. Git makes terminology a little confusing in that
part. Because the example I was thinking of is 'git status --porcelain'
which is meant to

   "Give the output in an easy-to-parse format for scripts. This is
    similar to the short output, but will remain stable across Git
    versions and regardless of user configuration."

In any case, the question is about output's stability.



Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Daniel Colascione-5
In reply to this post by Dmitry Gutov
> Hi Andrii,
>
> On 26.11.2019 17:16, Andrii Kolomoiets wrote:
>
>> By invoking single 'summary' command we can get more info about
>> repository state: parent revisions, current branch, tags, bookmarks,
>> commit status, available updates and phase.
>
> I guess the questions are:
>
> - Is this output better than the previous one? Hopefully others will
> chime in, e.g. Daniel, who wrote some major improvements to vc-hg a few
> years ago.
>
> - Is 'hg summary' stable enough? Maybe a few years from now Mercurial
> changes its output and this code stops working in all Emacs we'd have
> released in the meantime? This is why we try to use "porcelain" level
> commands (in Git terminology) when possible, not user-level.
>

What's the performance of summary like these days?





Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Andrii Kolomoiets
On 27 Nov 2019, at 20:53, Daniel Colascione <[hidden email]> wrote:

>
>> Hi Andrii,
>>
>> On 26.11.2019 17:16, Andrii Kolomoiets wrote:
>>
>>> By invoking single 'summary' command we can get more info about
>>> repository state: parent revisions, current branch, tags, bookmarks,
>>> commit status, available updates and phase.
>>
>> I guess the questions are:
>>
>> - Is this output better than the previous one? Hopefully others will
>> chime in, e.g. Daniel, who wrote some major improvements to vc-hg a few
>> years ago.

Current output displays current branch and tag. There are also root dir,
but vc displays working dir itself, so root is not needed.
BTW root can be replaced with bookmark because bookmark is what
vc-hg-create-tag create when branchp.  From user's POV the branch
creation is not working:
1. Open vc-dir for hg repository
2. C-u B c
3. Enter branch name to create
and nothing changed in vc-dir - branch and tag are remains the same.

Info that 'summary' shows but missed in the current output:

- Parent revision and first line of commit message.
  During merge both parents are shown.  Very handy.
  This info can be obtained by parsing 'hg log' command output.

- Bookmarks, if any.
  Can be obtained by 'hg id -B'.

- Commit state.
  Shows the count of modified, added, removed, renamed, copied, deleted,
  unknown and unresolved files.  Alright, all affected files are listed
  in the same vc-dir buffer and one can count them so those numbers may
  be not very interesting.
  But commit state also can show if graft, update or merge is in
  progress; if head are closed; if it is a new branch; if there are
  changes in subrepositories.  I don't know how to obtain this info.

- Update state.
  Shows the available updates count and/or branch heads count.
  I don't know how obtain this info, maybe some log command.

- Number of incoming and outgoing changes (with '--remote' switch).
  It is slow, but we can allow user to decide use it or not.

- Phase.  Can show how many changesets are not shared yet.

IMO 'summary' gives better overview of repo state.


>> - Is 'hg summary' stable enough? Maybe a few years from now Mercurial
>> changes its output and this code stops working in all Emacs we'd have
>> released in the meantime? This is why we try to use "porcelain" level
>> commands (in Git terminology) when possible, not user-level.

This code do nothing but propertize the text.  We just show the user the
output of the user command.

The layout can be messed though if the name-value separator will be
changed. To solve this the regexp can be put into the variable so it can
be changed easily.  Removal of the 'summary' command is the worst case.
But AFAIK there are no prerequisites for this.  Let's not hide usefull
info from the user because we affraid of hypothetical removal of the
'summary' command :)
For now, comparing 'summary' output of hg 2.6.2 and 5.2, I can see that
phase info is added in recent version and no breaking changes at all.


> What's the performance of summary like these days?

Let's see.

  hg summary  0.21s user 0.16s system 98% cpu 0.376 total

  hg log -r 'p1(.)+p2(.)'  0.14s user 0.08s system 99% cpu 0.221 total
  hg id --branch  0.14s user 0.13s system 98% cpu 0.280 total
  hg id --tags  0.15s user 0.14s system 98% cpu 0.299 total
  hg id --bookmarks  0.15s user 0.15s system 98% cpu 0.298 total
  hg phase  0.12s user 0.07s system 97% cpu 0.193 total

Yes, 'summary' is slower than single 'id' command. But again, it is
faster to run a single command that gives all the info rather than run
five different commands. Imagine working with repo over TRAMP.


Best regards.



Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Andrii Kolomoiets
In reply to this post by Andrii Kolomoiets
Patch is slightly modified to match all whitespaces after ':' to handle possible extra spaces in 'summary' output.


0001-vc-hg-use-hg-summary-to-populate-extra-vc-dir-header.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Dmitry Gutov
In reply to this post by Daniel Colascione-5
On 27.11.2019 20:53, Daniel Colascione wrote:
> What's the performance of summary like these days?

Speaking of performance, 'hg summary' on my old mozilla-central checkout
takes about 1.2 sec. But the current impl is not instantaneous either.



Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Dmitry Gutov
In reply to this post by Andrii Kolomoiets
On 28.11.2019 10:07, Andrii Kolomoiets wrote:

> Current output displays current branch and tag. There are also root dir,
> but vc displays working dir itself, so root is not needed.
> BTW root can be replaced with bookmark because bookmark is what
> vc-hg-create-tag create when branchp.  From user's POV the branch
> creation is not working:
> 1. Open vc-dir for hg repository
> 2. C-u B c
> 3. Enter branch name to create
> and nothing changed in vc-dir - branch and tag are remains the same.

Should it actually created branches instead? Or do Mercurial branches
differ sufficiently from the same concept in other VCS?

Could anybody say why vc-hg-create-tag has been using bookmarks from the
outset?

> Info that 'summary' shows but missed in the current output:
>
> - Parent revision and first line of commit message.
>    During merge both parents are shown.  Very handy.
>    This info can be obtained by parsing 'hg log' command output.
>
> - Bookmarks, if any.
>    Can be obtained by 'hg id -B'.
>
> - Commit state.
>    Shows the count of modified, added, removed, renamed, copied, deleted,
>    unknown and unresolved files.  Alright, all affected files are listed
>    in the same vc-dir buffer and one can count them so those numbers may
>    be not very interesting.
>    But commit state also can show if graft, update or merge is in
>    progress; if head are closed; if it is a new branch; if there are
>    changes in subrepositories.  I don't know how to obtain this info.
>
> - Update state.
>    Shows the available updates count and/or branch heads count.
>    I don't know how obtain this info, maybe some log command.
>
> - Number of incoming and outgoing changes (with '--remote' switch).
>    It is slow, but we can allow user to decide use it or not.
>
> - Phase.  Can show how many changesets are not shared yet.
>
> IMO 'summary' gives better overview of repo state.

I'd like to hear from others about how crucial this info is.

FWIW, I'm usually okay with the minimal VC-Dir output that vc-git does.

>>> - Is 'hg summary' stable enough? Maybe a few years from now Mercurial
>>> changes its output and this code stops working in all Emacs we'd have
>>> released in the meantime? This is why we try to use "porcelain" level
>>> commands (in Git terminology) when possible, not user-level.
>
> This code do nothing but propertize the text.  We just show the user the
> output of the user command.

It would be a shame if it breaks anyway.

> The layout can be messed though if the name-value separator will be
> changed. To solve this the regexp can be put into the variable so it can
> be changed easily.  Removal of the 'summary' command is the worst case.
> But AFAIK there are no prerequisites for this.  Let's not hide usefull
> info from the user because we affraid of hypothetical removal of the
> 'summary' command :)
> For now, comparing 'summary' output of hg 2.6.2 and 5.2, I can see that
> phase info is added in recent version and no breaking changes at all.

Moving the regexp into a var could alleviate the biggest part of the
risk, indeed.

>> What's the performance of summary like these days?
>
> Let's see.
>
>    hg summary  0.21s user 0.16s system 98% cpu 0.376 total
>
>    hg log -r 'p1(.)+p2(.)'  0.14s user 0.08s system 99% cpu 0.221 total
>    hg id --branch  0.14s user 0.13s system 98% cpu 0.280 total
>    hg id --tags  0.15s user 0.14s system 98% cpu 0.299 total
>    hg id --bookmarks  0.15s user 0.15s system 98% cpu 0.298 total
>    hg phase  0.12s user 0.07s system 97% cpu 0.193 total
>
> Yes, 'summary' is slower than single 'id' command.

We're not comparing against a single one. Would it be faster than what
we do now? The comparison above seems like it would?

> But again, it is
> faster to run a single command that gives all the info rather than run
> five different commands. Imagine working with repo over TRAMP.

TRAMP is an okay argument, too.



Reply | Threaded
Open this post in threaded view
|

bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Daniel Colascione-5


On 12/1/19 4:31 PM, Dmitry Gutov wrote:

> On 28.11.2019 10:07, Andrii Kolomoiets wrote:
>
>> Current output displays current branch and tag. There are also root dir,
>> but vc displays working dir itself, so root is not needed.
>> BTW root can be replaced with bookmark because bookmark is what
>> vc-hg-create-tag create when branchp.  From user's POV the branch
>> creation is not working:
>> 1. Open vc-dir for hg repository
>> 2. C-u B c
>> 3. Enter branch name to create
>> and nothing changed in vc-dir - branch and tag are remains the same.
>
> Should it actually created branches instead? Or do Mercurial branches
> differ sufficiently from the same concept in other VCS?
>
> Could anybody say why vc-hg-create-tag has been using bookmarks from the
> outset?
>
>> Info that 'summary' shows but missed in the current output:
>>
>> - Parent revision and first line of commit message.
>>    During merge both parents are shown.  Very handy.
>>    This info can be obtained by parsing 'hg log' command output.
>>
>> - Bookmarks, if any.
>>    Can be obtained by 'hg id -B'.
>>
>> - Commit state.
>>    Shows the count of modified, added, removed, renamed, copied, deleted,
>>    unknown and unresolved files.  Alright, all affected files are listed
>>    in the same vc-dir buffer and one can count them so those numbers may
>>    be not very interesting.
>>    But commit state also can show if graft, update or merge is in
>>    progress; if head are closed; if it is a new branch; if there are
>>    changes in subrepositories.  I don't know how to obtain this info.
>>
>> - Update state.
>>    Shows the available updates count and/or branch heads count.
>>    I don't know how obtain this info, maybe some log command.
>>
>> - Number of incoming and outgoing changes (with '--remote' switch).
>>    It is slow, but we can allow user to decide use it or not.
>>
>> - Phase.  Can show how many changesets are not shared yet.
>>
>> IMO 'summary' gives better overview of repo state.
>
> I'd like to hear from others about how crucial this info is.
>
> FWIW, I'm usually okay with the minimal VC-Dir output that vc-git does.
>
>>>> - Is 'hg summary' stable enough? Maybe a few years from now Mercurial
>>>> changes its output and this code stops working in all Emacs we'd have
>>>> released in the meantime? This is why we try to use "porcelain" level
>>>> commands (in Git terminology) when possible, not user-level.
>>
>> This code do nothing but propertize the text.  We just show the user the
>> output of the user command.
>
> It would be a shame if it breaks anyway.
>
>> The layout can be messed though if the name-value separator will be
>> changed. To solve this the regexp can be put into the variable so it can
>> be changed easily.  Removal of the 'summary' command is the worst case.
>> But AFAIK there are no prerequisites for this.  Let's not hide usefull
>> info from the user because we affraid of hypothetical removal of the
>> 'summary' command :)
>> For now, comparing 'summary' output of hg 2.6.2 and 5.2, I can see that
>> phase info is added in recent version and no breaking changes at all.
>
> Moving the regexp into a var could alleviate the biggest part of the
> risk, indeed.
>
>>> What's the performance of summary like these days?
>>
>> Let's see.
>>
>>    hg summary  0.21s user 0.16s system 98% cpu 0.376 total
>>
>>    hg log -r 'p1(.)+p2(.)'  0.14s user 0.08s system 99% cpu 0.221 total
>>    hg id --branch  0.14s user 0.13s system 98% cpu 0.280 total
>>    hg id --tags  0.15s user 0.14s system 98% cpu 0.299 total
>>    hg id --bookmarks  0.15s user 0.15s system 98% cpu 0.298 total
>>    hg phase  0.12s user 0.07s system 97% cpu 0.193 total
>>
>> Yes, 'summary' is slower than single 'id' command.
>
> We're not comparing against a single one. Would it be faster than what
> we do now? The comparison above seems like it would?
>
>> But again, it is
>> faster to run a single command that gives all the info rather than run
>> five different commands. Imagine working with repo over TRAMP.
>
> TRAMP is an okay argument, too.

I care mostly about the latency of visiting individual files. That
*must* be fast. If this is something that runs only on vc-dir, that's
probably fine.