Re: changeset included in a particular tag

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

Re: changeset included in a particular tag

Mike Miller
Hi Glenn, I'm moving this to the maintainers list, this is the best
place to discuss development or ask questions about the Octave mercurial
repository (and bring the answers to the attention of other developers).

On Mon, Feb 03, 2014 at 22:18:40 +0000, Glenn Golden wrote:

> A question though: This is not specific to this bug but I'll ask it here
> anyway: Not being familiar with Mercurial, I'm wondering what is the "correct"
> way to determine whether a given commit is present within a specific numbered
> version of Octave (as reported by version())?  I looked at the "log" view of
> the commit list
>
>    http://hg.savannah.gnu.org/hgweb/octave/log
>
> but the only thing I see giving a hint about the points in time at which
> numbered releases were made is entries with descriptive text like "snapshot
> x.y.z". Such entries can of course be located via search within the list using
> that "snapshot" keyword, and then the date compared to the date of the commit
> you're interesting in knowing about. But I'm wondering if there's a more
> streamlined way to accomplish this?

I've found the following two mercurial patterns useful.

1.

  hg log -r "tag() and d99785217634::" --template "{tags}\n"

This one lists all tags in the working repository that have been made
since the specified changeset. This is roughly like the git command
"git tag --contains".

2.

  hg log -r "d99785217634 and ::tag(\"release-3-8-0\")"

This lists the given changeset if and only if it is a proper ancestor of
the specified tag "release-3-8-0" (in this case it is). If I substitute
a newer changeset, e.g. the tip of the default branch right now,

  hg log -r "cb377af34c00 and ::tag(\"release-3-8-0\")"

then I get no output, meaning it is not present in the history of the
specified tag.

See "hg help revsets" for more ways to extract subsets of the history.

Others (esp. Jordi) may have other mercurial wisdom.

HTH,

--
mike
Reply | Threaded
Open this post in threaded view
|

Re: changeset included in a particular tag

Jordi Gutiérrez Hermoso-2
On Mon, 2014-02-03 at 20:26 -0500, Mike Miller wrote:

> I've found the following two mercurial patterns useful.
>
> 1.
>
>   hg log -r "tag() and d99785217634::" --template "{tags}\n"
>
> This one lists all tags in the working repository that have been made
> since the specified changeset. This is roughly like the git command
> "git tag --contains".
>
> 2.
>
>   hg log -r "d99785217634 and ::tag(\"release-3-8-0\")"
>
> This lists the given changeset if and only if it is a proper ancestor of
> the specified tag "release-3-8-0" (in this case it is). If I substitute
> a newer changeset, e.g. the tip of the default branch right now,
>
>   hg log -r "cb377af34c00 and ::tag(\"release-3-8-0\")"
>
> then I get no output, meaning it is not present in the history of the
> specified tag.
>
> See "hg help revsets" for more ways to extract subsets of the history.
>
> Others (esp. Jordi) may have other mercurial wisdom.

These are all good revsets. I'm glad someone other than me is actually
using revsets! They're a very powerful DSL for inspecting hg history.

By the way, newer Mercurial versions allow revsets in hgweb searches,
so that we could use urls that contain revset queries. This would
require upgrading Savannah's Debian OS, which should be done anyway.
Is there interest in this? If so, I could consult with the Savannah
hackers about doing server upgrades.

- Jordi G. H.


Reply | Threaded
Open this post in threaded view
|

Re: changeset included in a particular tag

Mike Miller
On Mon, Feb 03, 2014 at 21:59:07 -0500, Jordi Gutiérrez Hermoso wrote:
> By the way, newer Mercurial versions allow revsets in hgweb searches,
> so that we could use urls that contain revset queries. This would
> require upgrading Savannah's Debian OS, which should be done anyway.
> Is there interest in this? If so, I could consult with the Savannah
> hackers about doing server upgrades.

Yes, for my part I'd say that would be a great feature to have. Glenn
replied privately to me saying that that is actually closer to what he
is looking for, a way for a user (not a developer) to see whether a
particular changeset is present in a particular (tagged and released)
Octave version, without having to clone the repository.

I see now running "hg serve" gives me that revset querying feature, and
also a nice infinite scroll in the log and graph views, both very nice
improvements over what savannah is running now.

--
mike
Reply | Threaded
Open this post in threaded view
|

Re: changeset included in a particular tag

Daniel Sebald
On 02/03/2014 10:44 PM, Mike Miller wrote:

> On Mon, Feb 03, 2014 at 21:59:07 -0500, Jordi Gutiérrez Hermoso wrote:
>> By the way, newer Mercurial versions allow revsets in hgweb searches,
>> so that we could use urls that contain revset queries. This would
>> require upgrading Savannah's Debian OS, which should be done anyway.
>> Is there interest in this? If so, I could consult with the Savannah
>> hackers about doing server upgrades.
>
> Yes, for my part I'd say that would be a great feature to have. Glenn
> replied privately to me saying that that is actually closer to what he
> is looking for, a way for a user (not a developer) to see whether a
> particular changeset is present in a particular (tagged and released)
> Octave version, without having to clone the repository.
>
> I see now running "hg serve" gives me that revset querying feature, and
> also a nice infinite scroll in the log and graph views, both very nice
> improvements over what savannah is running now.

I was going to mention something along these lines a few days ago when I
noticed that the default Mercurial server has something called "file
log" which is a nice option for seeing the history of just a particular
file.  But that doesn't appear on Savannah.

I've just now gone to

http://hg.savannah.gnu.org/hgweb/octave/

and did a search with a changeset from a few weeks ago: bd9d34f28b0f

That changeset appears first in the list.  Selecting the line bring up
the webpage associate with the changeset.  Selecting "graph" then goes
to the point in the graph where the changeset is.

Is that enough to determine if the changeset is in a particular branch?
  Or is the preferred result more of a yes/no type of command?

Is it possible to do a test run on applying a changeset if it is a diff
file?  Mercurial should complain if the changeset has already been applied.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: changeset included in a particular tag

Glenn Golden
--
On 02/03/2014 10:44 PM, Mike Miller wrote:
> >
> >Yes, for my part I'd say that would be a great feature to have. Glenn
> >replied privately to me saying that that is actually closer to what he
> >is looking for, a way for a user (not a developer) to see whether a
> >particular changeset is present in a particular (tagged and released)
> >Octave version, without having to clone the repository.
> >

Yes, my original question was too sparse, so let me expand on it a bit.

The question was whether there exists some "standard" way for an ordinary
user like myself -- as opposed to a developer, who presumably has access
to various Mercurial tools on his system -- to determine whether a particular
changeset is present in the numbered released version of Octave that he
happens to be using.

This is an essential need when filing bug reports: During his search to see
whether the bug has already been reported, the reporter may come across a
changeset that claims to have fixed it, or is related to it. Should he file
the report or not? It depends on the time relationship between the changeset
and the Octave version() in which he noticed the putative bug. If his version
doesn't include the bugfix changeset, then of course it doesn't make sense to
file the report and waste developers' time reporting something that has
potentially been taken care of already.  Otoh, if his Octave version was
created after the changeset date, then he probably wants to file the report
stating that the problem is not fixed, or not fixed entirely, or whatever
the case may be.



Daniel J Sebald <[hidden email]> [2014-02-03 23:09:18 -0600]:

>
> I was going to mention something along these lines a few days ago when I
> noticed that the default Mercurial server has something called "file log"
> which is a nice option for seeing the history of just a particular file.
> But that doesn't appear on Savannah.
>
> I've just now gone to
>
> http://hg.savannah.gnu.org/hgweb/octave/
>
> and did a search with a changeset from a few weeks ago: bd9d34f28b0f
>
> That changeset appears first in the list.  Selecting the line bring up the
> webpage associate with the changeset.  Selecting "graph" then goes to the
> point in the graph where the changeset is.
>
> Is that enough to determine if the changeset is in a particular branch?  Or
> is the preferred result more of a yes/no type of command?
>

I did something similar, except searched for the string "snapshot", after
noticing in the web-based Mercurial log that John seems to have been
consistently titling the numbered releases as such.  Unfortunately, the result
from that search gives the list of dates in useless fuzzy-relative form
("8 months ago") but if you click on each one, you can learn the exact release
snapshot date from the log entry. Then you can compare those dates to the date
of any particular changeset that you're interested in.

The above is not difficult, but I was just wondeirng if there was a less
"manual" way to accomplish the same thing. It seems like it ought to be a
fairly standard thing that folks want to do pretty often.



snapshot_kwd_examp.png (68K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: changeset included in a particular tag

Jordi Gutiérrez Hermoso-2
On Tue, 2014-02-04 at 18:13 -0700, Glenn Golden wrote:

> The question was whether there exists some "standard" way for an ordinary
> user like myself -- as opposed to a developer, who presumably has access
> to various Mercurial tools on his system --

There is nothing different between a standard user and a developer.
Just install Mercurial and answer the questions you want answered.
Anyone can download and install Mercurial.

> This is an essential need when filing bug reports: During his search
> to see whether the bug has already been reported, the reporter may
> come across a changeset that claims to have fixed it, or is related
> to it. Should he file the report or not?

Although this question can be answered more easily by making revset
queries via the hgweb interface should I get around to updating the
server version, you can currently answer it by installing Mercurial
yourself.

- Jordi G. H.


Reply | Threaded
Open this post in threaded view
|

Re: changeset included in a particular tag

Daniel Sebald
In reply to this post by Glenn Golden
On 02/04/2014 07:13 PM, Glenn Golden wrote:

> Daniel J Sebald<[hidden email]>  [2014-02-03 23:09:18 -0600]:
>>
>> I was going to mention something along these lines a few days ago when I
>> noticed that the default Mercurial server has something called "file log"
>> which is a nice option for seeing the history of just a particular file.
>> But that doesn't appear on Savannah.
>>
>> I've just now gone to
>>
>> http://hg.savannah.gnu.org/hgweb/octave/
>>
>> and did a search with a changeset from a few weeks ago: bd9d34f28b0f
>>
>> That changeset appears first in the list.  Selecting the line bring up the
>> webpage associate with the changeset.  Selecting "graph" then goes to the
>> point in the graph where the changeset is.
>>
>> Is that enough to determine if the changeset is in a particular branch?  Or
>> is the preferred result more of a yes/no type of command?
>>
>
>
> I did something similar, except searched for the string "snapshot", after
> noticing in the web-based Mercurial log that John seems to have been
> consistently titling the numbered releases as such.  Unfortunately, the result
> from that search gives the list of dates in useless fuzzy-relative form
> ("8 months ago") but if you click on each one, you can learn the exact release
> snapshot date from the log entry. Then you can compare those dates to the date
> of any particular changeset that you're interested in.

I don't like the relative age list either.  In the past when searching
for when a bug might have found its way into the code I much prefer an
actual date in the list.  It depends actually.  If the changeset is
within the past few days, or day, then relative age is somewhat useful.
  But not when it gets beyond a week and there are hundreds of
changesets for which to guess "60 previous" or "120 previous", etc.


> The above is not difficult, but I was just wondeirng if there was a less
> "manual" way to accomplish the same thing. It seems like it ought to be a
> fairly standard thing that folks want to do pretty often.

Maybe a nice starting project for someone inquiring about contributing
would be to build an Octave-specific command "mercurial" that does a few
simple things _if_ the tools happen to be present on the user's machine.
  (I.e., don't make such a function part of the install script... just
tell the user what is missing at run time.)

For example, perhaps:

> mercurial('changeset')

ans = '132667955f66'

The changeset ID can be gotten at compile time from the following:

[sebald src]# hg id
132667955f66+ tip

Note that the + appeared because I edited one of the files so that there
are some uncommitted changes.  It shouldn't be too difficult to
incorporate the "hg id" command into a Makefile, I would think.

How about:

> mercurial('clone')

will use some of the new dialog boxes to ask the user if s/he would like
to clone the repository, choose the directory where to place it, then
proceed to issue the system commands and internet addresses that will do
the clone.  It could launch tortoise-hg and update to the ID number that
is gotten from the "mercurial('changeset')" command.

Does that seem like something useful Glenn?  Might be a good GSOC project.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: changeset included in a particular tag

Jordi Gutiérrez Hermoso-2
In reply to this post by Jordi Gutiérrez Hermoso-2
On Wed, 2014-02-05 at 20:56 -0500, Jordi Gutiérrez Hermoso wrote:
> On Tue, 2014-02-04 at 18:13 -0700, Glenn Golden wrote:

> > This is an essential need when filing bug reports: During his search
> > to see whether the bug has already been reported, the reporter may
> > come across a changeset that claims to have fixed it, or is related
> > to it. Should he file the report or not?
>
> Although this question can be answered more easily by making revset
> queries via the hgweb interface should I get around to updating the
> server version, you can currently answer it by installing Mercurial
> yourself.

Good news, I got around to it. We are now running Mercurial 2.8 in
Savannah. This now allows us to make revset queries to answer your
original questions by using the web interface:

    http://hg.savannah.gnu.org/hgweb/octave/log?rev=tag%28%29+and+d99785217634%3A%3A

    http://hg.savannah.gnu.org/hgweb/octave/log?rev=d99785217634+and+%3A%3Atag%28%22release-3-8-0%22%29
   
    http://hg.savannah.gnu.org/hgweb/octave/log?rev=cb377af34c00+and+%3A%3Atag%28%22release-3-8-0%22%29

This is thanks to some cool GSoC 2013 work that happend on Mercurial.
And just because I like hg, here is a nice blog post praising it:

    http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercurial-%28and-git%29/

HTH,
- Jordi G. H.


Reply | Threaded
Open this post in threaded view
|

Couple of questions on Savannah account configuration

Glenn Golden
In reply to this post by Daniel Sebald
--
Please excuse the somewhat off-topic queries below, but I got no response to
a ticket I filed with the Savannah top-level support list (#108500) asking the
first one of these questions, so it seemed pointless to file yet another ticket
asking the second question too.  So I'll just ask them here: Hope you don't
mind.

  1. In the account configuration page

        https://savannah.gnu.org/my/admin/change_notifications.php 

     there's an option ("Subject Line") to allow the user to specify a custom
     'Subject' line for messages. But it doesn't seem to have any effect on
     messages received from the Octave tracker. I changed it several days ago
     to a custom value, yet all received messages from the Octave tracker
     still have the standard header. And I couldn't find any per-project way
     to do this.

  2. Also regarding Savannah account configuration: Is there a way to
     _temporarily_ disable/enable traffic from the list?  In the account
     configuraiton section, there's a page that seems to address this need

        https://savannah.gnu.org/my/admin/cc.php

     but it also indicates that if you remove yourself from the Cc list, that
     removal is permanent and cannot be undone:

         " Beware: this process cannot be undone, you will be definitely
           removed from carbon-copy lists of any items of the selected groups."

     There's also a set of checkboxes here

        https://savannah.gnu.org/my/admin/change_notifications.php

     but none of them seem to be of the "all messages on/off" variety, and
     even after having tried some of them (out of desperation) they seem to
     have no effect.

TIA,

Glenn
Reply | Threaded
Open this post in threaded view
|

Re: Couple of questions on Savannah account configuration

Daniel Sebald
On 02/11/2014 01:34 PM, Glenn Golden wrote:

>    2. Also regarding Savannah account configuration: Is there a way to
>       _temporarily_ disable/enable traffic from the list?  In the account
>       configuraiton section, there's a page that seems to address this need
>
> https://savannah.gnu.org/my/admin/cc.php

Glenn,

This list doesn't use Savannah as far as I know.  We only use limited
features of the Savannah system for bug/patch tracking.

The list subscription is described here:

http://www.gnu.org/software/octave/get-involved.html

Follow the link [hidden email].  Once subscribed you can later
configure the account and traffic.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: Couple of questions on Savannah account configuration

Glenn Golden
--
Hi Dan,

Daniel J Sebald <[hidden email]> [2014-02-11 22:26:09 -0600]:
>
> This list doesn't use Savannah as far as I know.  We only use limited
> features of the Savannah system for bug/patch tracking.
>

I understand that this list doesn't use Savannah. The questions pertained to
my account on the bug tracker itself:

    https://savannah.gnu.org/bugs/?group=octave

The only reason I posted my questions to this list was because I thought
someone here might have run into the same issues about configuring their
Savannah tracker account vis a vis controlling email traffic. I originally
posted the first question to the tracker support list itself, which seems
like the appropriate place; but received no reply, so probably no one is
minding that list.

Thanks for your reply in any case.

Glenn
Reply | Threaded
Open this post in threaded view
|

Re: Couple of questions on Savannah account configuration

Glenn Golden
In reply to this post by Daniel Sebald
--
Dan,

Figured out what was going on: The bug report messages that I (mistakenly)
thought were originating from the Savannah tracker itself were actually just
Cc copies of those tracker messages being repeated on the gnu-octave list.

I'd totally forgotten that I had subscribed to that list. [Insert red-face
smiley here.]

Anyway, sorry for the noise, and thanks for your input on this.

Glenn



Daniel J Sebald <[hidden email]> [2014-02-11 22:26:09 -0600]:

> On 02/11/2014 01:34 PM, Glenn Golden wrote:
>
> >   2. Also regarding Savannah account configuration: Is there a way to
> >      _temporarily_ disable/enable traffic from the list?  In the account
> >      configuraiton section, there's a page that seems to address this need
> >
> > https://savannah.gnu.org/my/admin/cc.php
>
> Glenn,
>
> This list doesn't use Savannah as far as I know.  We only use limited
> features of the Savannah system for bug/patch tracking.
>
> The list subscription is described here:
>
> http://www.gnu.org/software/octave/get-involved.html
>
> Follow the link [hidden email].  Once subscribed you can later
> configure the account and traffic.
>
> Dan