Re: changeset included in a particular tag

[Daniel J Sebald]

On 02/04/2014 07:13 PM, Glenn Golden wrote:

> Daniel J Sebald<address@hidden>  [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