<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general">
    <title>gmane.comp.version-control.mercurial.general</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31062"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31061"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31060"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31059"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31058"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31057"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31056"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31055"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31054"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31053"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31052"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31051"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31050"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31049"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31048"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31047"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31046"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31045"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31044"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31043"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31062">
    <title>THG -- tab hover-tip for repo path?</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31062</link>
    <description>&lt;pre&gt;(I know, not a general Hg question.  Sorry)

Is it a reasonable suggestion to request a hovertip for the Workbench
/when you hover over the tab/?  That shows the path to the repo?

 I know there are hovertips for the path in the Repository Registry pane, but
   a) I often have the primary repo and its clone open on adjacent tabs
   b) I sometimes can't tell which registry item is _bolded_ (and that
shows the correspondence of the active tab to the registry)

I'd be happy also with a static display, but the space on the tab body
is kinda crowded; the biggest open area is to the left of Commit
button.

Thanks.

/dps

&lt;/pre&gt;</description>
    <dc:creator>Dave S</dc:creator>
    <dc:date>2012-05-25T23:07:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31061">
    <title>RE: Use hg commit --amend to change the files that are included inacommit</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31061</link>
    <description>&lt;pre&gt;...


But the actual definition of amend is to alter something that already exists, not to redo it from scratch. As a non-mq user, I think if amend was changed to mean "redo the commit from scratch" it would be unintuitive for a lot of people.

Mischa



________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
&lt;/pre&gt;</description>
    <dc:creator>Becker, Mischa J</dc:creator>
    <dc:date>2012-05-25T22:42:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31060">
    <title>Re: Use hg commit --amend to change the files that are included in acommit</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31060</link>
    <description>&lt;pre&gt;On Fri, May 25, 2012 at 5:08 PM, Angel Ezquerra
&amp;lt;angel.ezquerra&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

As a data point, for several years MercurialEclipse has supported
amend on commit and it works exactly as the new commit --amend works.
&lt;/pre&gt;</description>
    <dc:creator>John Peberdy</dc:creator>
    <dc:date>2012-05-25T21:42:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31059">
    <title>Re: Bookmarks guide</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31059</link>
    <description>&lt;pre&gt;On Fri, May 25, 2012 at 10:24 PM, Angel Ezquerra
&amp;lt;angel.ezquerra&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

You can get the same result with "head() and branch(branchname)"

Simon
&lt;/pre&gt;</description>
    <dc:creator>Simon King</dc:creator>
    <dc:date>2012-05-25T21:34:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31058">
    <title>Re: Bookmarks guide</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31058</link>
    <description>&lt;pre&gt;
OK, I get it now :-)

FWIW it was easier to understand by looking at the code in revset.py
than by reading the description given by hg help revsets.

Would it make sense to let head() accept an argument which specified
the branch we want the head to belong to?

Angel
&lt;/pre&gt;</description>
    <dc:creator>Angel Ezquerra</dc:creator>
    <dc:date>2012-05-25T21:24:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31057">
    <title>Re: Use hg commit --amend to change the files that are included in acommit</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31057</link>
    <description>&lt;pre&gt;On Fri, May 25, 2012 at 5:35 PM, Pierre-Yves David
&amp;lt;pierre-yves.david&amp;lt; at &amp;gt;logilab.fr&amp;gt; wrote:

I think commit --amend is not very widely used yet but I've been
encouraging people around here to use it instead of using mq. I got
the impression that the mental model that people have of amend is
"redo the commit" (as in redo it from scratch).

This may be because that is the model that _I_ had in the first place
(and I am the one explaining it to people). However I think that the
"new commit + qfold" model is too advanced for most basic users (who
may not even know what qfold is)! It makes sense if you think about it
and are an advanced mercurial user but I'm not sure it is something
that most users will easily grasp intuitively or without a proper
explanation.

Assuming that many users will think of amend as a way to "redo a
commit", not being able to chose which files are included in the
amended commit is likely to be confusing. It was confusing to me when
I discovered it, and a couple of guys have come telling me&lt;/pre&gt;</description>
    <dc:creator>Angel Ezquerra</dc:creator>
    <dc:date>2012-05-25T21:08:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31056">
    <title>Re: Bookmarks guide</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31056</link>
    <description>&lt;pre&gt;
Think harder, please.

&lt;/pre&gt;</description>
    <dc:creator>Matt Mackall</dc:creator>
    <dc:date>2012-05-25T21:07:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31055">
    <title>Re: Bookmarks guide</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31055</link>
    <description>&lt;pre&gt;
I had read that but I do not see much difference. It seems a bit
redundant... "heads()" (with no argument) could also return "Changeset
that is a named branch head". This would have the added benefit that
its name would be the same as the "heads" command.

Angel
&lt;/pre&gt;</description>
    <dc:creator>Angel Ezquerra</dc:creator>
    <dc:date>2012-05-25T20:40:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31054">
    <title>Re: Bookmarks guide</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31054</link>
    <description>&lt;pre&gt;
Compare:

    "head()"
      Changeset is a named branch head.

    "heads(set)"
      Members of set with no children in set.

&lt;/pre&gt;</description>
    <dc:creator>Matt Mackall</dc:creator>
    <dc:date>2012-05-25T16:53:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31053">
    <title>Re: SVN-Mercurial conversion problems</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31053</link>
    <description>&lt;pre&gt;
That direction is usually not used by Mercurial developers and might be 
less tested than the opposite direction ;-)


 From 'hg help -v convert':
  -v --verbose           enable additional output
     --debug             enable debugging output

The following might help developers figuring out exactly where in the 
process it failed:
     --traceback         always print a traceback on exception


Yes - and subversion python bindings is used for converting from 
subversion. Combining different versions might be confusing.

/Mads
&lt;/pre&gt;</description>
    <dc:creator>Mads Kiilerich</dc:creator>
    <dc:date>2012-05-25T16:27:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31052">
    <title>Re: Tracking repository version numbers between releases</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31052</link>
    <description>&lt;pre&gt;
That's certainly good if you already know it's a template. I 
half-remembered this feature, poked around in the help hg id and hg log, 
and found nothing.

tom

&lt;/pre&gt;</description>
    <dc:creator>Tom Anderson</dc:creator>
    <dc:date>2012-05-25T16:19:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31051">
    <title>SVN-Mercurial conversion problems</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31051</link>
    <description>&lt;pre&gt;Hi,

I'm trying to use the Convert Extension for converting multiple Mercurial
repositories to Subversion repositories.
Conversion fails for some repositories with errors like this:

hg convert --dest-type svn foobar-hg foobar-svn

...
118 cleanups
abort: svn exited with status 256

and another repository conversion fails with this error:

...
71 cleanup
unexpected svn output:
abort: unable to cope with svn output

Any suggestions for finding out the cause for these conversion failures?
Are there any other tools or methods I could try out for the conversion?

After successful conversion, hg reports that tags are not converted.
How could I get the tags also converted?

I'm using the following software versions:
Mercurial 2.2.1+20120504
Subversion 1.7.4 (r1295709). I've several Subversion versions installed.
How does Mercurial determine which one to use? Does it use the first one
found in $PATH?


thanks,
marko
&lt;/pre&gt;</description>
    <dc:creator>Marko Asplund</dc:creator>
    <dc:date>2012-05-25T16:04:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31050">
    <title>Re: Tracking repository version numbers between releases</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31050</link>
    <description>&lt;pre&gt;On Fri May 25 08:18:29 CDT 2012, Simon King simon wrote
wrote:
wrote:
do:
in an
revsets.
something
write
latest
know).
your
wrapped ctx
however


Some sort of regexp search within -r 'tag()' would be extremely useful. A
build environment is often doing stuff analagous to release_notes=$(hg -v
log -r "::last(branch(default)) and not
::last(tagged(r'foo_bar-nightly\.N\.\d+')) and not merge()" ) .  And while
It's really no big deal to get the tag by piping hg tags through grep and
head, but it would turn lots of longer operations into one-liners with this
feature.

Steve
&lt;/pre&gt;</description>
    <dc:creator>Stephen Morton</dc:creator>
    <dc:date>2012-05-25T15:39:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31049">
    <title>Re: Use hg commit --amend to change the files that are included ina commit</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31049</link>
    <description>&lt;pre&gt;

In a world where you just "create" commit, you have two states to consider for file:

    1) "last" commit content (hg cat -r . babar.txt)
    2) current working directory content (cat babar.txt)

You can easily over of UI to say "pick (1) or (2)"

But in a world where you also rewrite commit you have three possible states to consider

    0) parent commit content (hg cat -r .^ babar.txt)
    1) "last" commit content (hg cat -r . babar.txt)
    C) current working directory content (cat babar.txt)

And it is more complicated to provide a UI to say "pick (0), (1) or (2)"

I think that the current commit --amend behavior (1) is the right one. Picking
(1) is consistent with the default behavior of commit. your amend will add to
history only changes you see with `hg status`  and `hg diff`.

I've see a lot a new comer confused by the (0) behavior of mq.


Yes handling the second situation would be useful. A dedicated "hg amend"
option to handle this advanced case (and other strange usecase) is probably a
better &lt;/pre&gt;</description>
    <dc:creator>Pierre-Yves David</dc:creator>
    <dc:date>2012-05-25T15:35:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31048">
    <title>Re: uisetup in record extension looks up mq - but the official docssay it shouldn't</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31048</link>
    <description>&lt;pre&gt;Le 17/05/12 15:58, Wujek Srujek a écrit :

This was changed by:

changeset:   9710:1765599f4899
user:        Martin Geisler &amp;lt;mg&amp;lt; at &amp;gt;lazybytes.net&amp;gt;
date:        Thu Nov 05 01:10:43 2009 +0100
files:       hgext/record.py
description:
record: use uisetup instead of extsetup to register qrecord

New commands should be registered in uisetup so that other extensions
have a chance of wrapping them in extsetup.


--
Patrick Mézard
&lt;/pre&gt;</description>
    <dc:creator>Patrick Mézard</dc:creator>
    <dc:date>2012-05-25T15:35:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31047">
    <title>Re: Tracking repository version numbers between releases</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31047</link>
    <description>&lt;pre&gt;
Proof of concept modification to the 'tag' revset expression:

diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1106,9 +1106,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
         tn = getstring(args[0],
                        # i18n: "tag" is a keyword
                        _('the argument to tag must be a string'))
-        if not repo.tags().get(tn, None):
-            raise util.Abort(_("tag '%s' does not exist") % tn)
-        s = set([cl.rev(n) for t, n in repo.tagslist() if t == tn])
+        s = set()
+        for t, n in repo.tagslist():
+            if re.search(tn, t):
+                s.add(cl.rev(n))
+        if not s:
+            raise util.Abort(_("no tags matching '%s' exist") % tn)
     else:
         s = set([cl.rev(n) for t, n in repo.tagslist() if t != 'tip'])
     return [r for r in subset if r in s]



The problem with this is that it requires patterns to be specified as
regular expressions. Is there any chance that this functionality would
be accepted if it a&lt;/pre&gt;</description>
    <dc:creator>Simon King</dc:creator>
    <dc:date>2012-05-25T13:18:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31046">
    <title>Re: Tracking repository version numbers between releases</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31046</link>
    <description>&lt;pre&gt;
I think it's pretty accesible:

    hg help templates

&lt;/pre&gt;</description>
    <dc:creator>Isaac Jurado</dc:creator>
    <dc:date>2012-05-25T13:17:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31045">
    <title>Re: Bookmarks guide</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31045</link>
    <description>&lt;pre&gt;On Fri, May 25, 2012 at 2:33 PM, Angel Ezquerra
&amp;lt;angel.ezquerra&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

According to the help, the heads() predicate is a kind of filter,
which only returns the changesets that have no children.  On the other
hand, the head() predicate is equivalent to "hg heads".

&lt;/pre&gt;</description>
    <dc:creator>Isaac Jurado</dc:creator>
    <dc:date>2012-05-25T13:14:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31044">
    <title>Re: Tracking repository version numbers between releases</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31044</link>
    <description>&lt;pre&gt;[SNIP]

Something that might help is if the 'tag([name])' revset expression
could accept patterns. Then you could write things like:

  hg log -r 'last(ancestors(.) and tag("dev-*"))'

...to get the latest dev tag, and

  hg log -r 'last(ancestors(.) and tag("release-*"))'

...to get the release tag.

FWIW, using a tag on an old revision to indicate what the *next*
version is going to be feels like an abuse of tags to me, but it's
your choice :-)

Simon
&lt;/pre&gt;</description>
    <dc:creator>Simon King</dc:creator>
    <dc:date>2012-05-25T12:56:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31043">
    <title>Re: Bookmarks guide</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31043</link>
    <description>&lt;pre&gt;At Fri, 25 May 2012 12:46:58 +0200,
Martin Geisler wrote:

I think you can have a “default” bookmark to which people will then
update on clone.
 
hg bookmark default -f # you need -f for this…

This will only work for the initial clone, though. You cannot just
create a tip bookmark (the real tip wins).

Best wishes,
Arne
_______________________________________________
Mercurial mailing list
Mercurial&amp;lt; at &amp;gt;selenic.com
http://selenic.com/mailman/listinfo/mercurial
&lt;/pre&gt;</description>
    <dc:creator>Arne Babenhauserheide</dc:creator>
    <dc:date>2012-05-25T12:35:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31042">
    <title>Re: Bookmarks guide</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/31042</link>
    <description>&lt;pre&gt;On Fri, May 25, 2012 at 1:31 PM, Angel Ezquerra
&amp;lt;angel.ezquerra&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

Actually I just realized that you can already do "heads(branch(default))".

Is there a reason why there is a head() and a heads() revset
predicate? couldn't "heads()" be the same as "head()"?

Angel
&lt;/pre&gt;</description>
    <dc:creator>Angel Ezquerra</dc:creator>
    <dc:date>2012-05-25T12:33:18</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.version-control.mercurial.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.version-control.mercurial.general</link>
  </textinput>
</rdf:RDF>

