From gregory.szorc at gmail.com  Wed Apr  1 18:53:20 2015
From: gregory.szorc at gmail.com (Gregory Szorc)
Date: Wed, 1 Apr 2015 16:53:20 -0700
Subject: list all paths from tag of remote hg repository without hg binary
In-Reply-To: <CAPkN8xKFwYgH99Dkai4axyC+qfYKN_Rz-v7zc5YBr-NM2QVugA@mail.gmail.com>
References: <CAPkN8x+8FjMVcE3A7A7rjHwTwjM-80Gnnw9cUVuMhmG4x5aKQw@mail.gmail.com>
	<19EC6BBE-933F-40F1-BC36-B373FED62246@durin42.com>
	<CAPkN8xL2VBdWnn2QYtG0PEuSfLHv9MaLwxzmAP14cszeEC-_iA@mail.gmail.com>
	<CAKQoGamufSF6azH+CFkNaN=ddJnfMjq8kvNSyyRs_iZ7sgUVXQ@mail.gmail.com>
	<CAPkN8xKFwYgH99Dkai4axyC+qfYKN_Rz-v7zc5YBr-NM2QVugA@mail.gmail.com>
Message-ID: <CAKQoGakPUmKx3CCBcbTKfuG_qrRR+QhrG=NqWd2+m7rBWYa3VA@mail.gmail.com>

JSON output will simply be a different "style." Just like you can prefix
handlers with "<style>-" or add ?style= to the query string to get e.g.
atom or rss, you'll be able to use "json."

Pull @, run `hg serve` and access a URL like http://localhost:8000/json-tags
.

We certainly could add any of the gazillion REST declaration resources to
hgweb's output. But at this point I'd like to make the API useful by
emitting useful data. Bonus features can come later. Or they can come now.
Patches welcome.

On Tue, Mar 31, 2015 at 2:01 AM, anatoly techtonik <techtonik at gmail.com>
wrote:

> On Mon, Mar 30, 2015 at 11:44 PM, Gregory Szorc <gregory.szorc at gmail.com>
> wrote:
>
>> On Mon, Mar 30, 2015 at 7:58 AM, anatoly techtonik <techtonik at gmail.com>
>> wrote:
>>
>>>
>>> On Mon, Mar 30, 2015 at 3:41 PM, Augie Fackler <raf at durin42.com> wrote:
>>>
>>>>
>>>> On Mar 30, 2015, at 7:41 AM, anatoly techtonik <techtonik at gmail.com>
>>>> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > I need to get stats about files additions and removals from Python
>>>> history. That means getting the list of all file paths for every existing
>>>> tag. It there a way to do this remotely, without clone checkout?
>>>> >
>>>> > I want the tool to be a simplistic web/JS dashboard that updates
>>>> itself automatically and doesn't run any server side binaries. Ideally I
>>>> want to do this operation in a series of web requests:
>>>> >
>>>> > 1. get all tags
>>>> > 2. for each tag get all files
>>>> >
>>>> > The output of `hg locate` is the ideal. Is it possible to get that
>>>> without hg binary and for remote repository?
>>>>
>>>> You can screen-scrape the output of hgweb, but I’m guessing the server
>>>> admins won’t like you much.
>>>>
>>>> Also, you’d be at the mercy of any HTML format changes in hgweb.
>>>>
>>>
>>> Is it possible to add a REST interface to hgweb? I doubt that the common
>>> operations will change often. As a side benefit, there will also be a
>>> details API usage stats.
>>>
>>
>> The URI space for hgweb is already RESTful. What's missing is an output
>> format tailored for machines. "raw" is the best we have, but it isn't good
>> enough.
>>
>> I started on a patch series to add a "json" style for the web interface
>> so ?style=json or "json-<cmd>" in the URIs would produce JSON (which could
>> be read by machines). I'd very much like to finish that work.
>> https://hg.mozilla.org/users/gszorc_mozilla.com/hg/rev/json-style if
>> someone wants to beat me to it.
>>
>> Also, the hgweb help output in @/to-be-3.4 contains detailed
>> documentation on all the URIs and their arguments.
>>
>
> Nice to know. What is the URL for that @/to-be-3.4 to look at?
>
> Maybe it will be better to add some integrity for REST APIs by defining a
> dedicated URL like https://hg.python.org/cpython/rest as an endpoint for
> both information about API and calls to it. Maybe with a link to some
> machine readable speccy like https://apiblueprint.org/ or http://raml.org/
>
> --
> anatoly t.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150401/0e875dcb/attachment.html>

From ndbecker2 at gmail.com  Thu Apr  2 08:19:31 2015
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 02 Apr 2015 09:19:31 -0400
Subject: question about fold
Message-ID: <mfjfl4$plj$1@ger.gmane.org>

This morning I copied some of my updates from machine 1 to machine 2.  
Everything was built fine on m1, so I pulled the update to m2.  But it 
didn't build on m2.  I had forgotten to add/ci some files.  So I fixed that 
on m1 and pulled to m2.

So this would seem like a perfect use for fold.  Now I have 2 different 
commits, the first says:

added feature foo

and 2nd says:

more foo

or something to that effect.

But I can't use fold, because fold refused to operate on 'public' repos.

So finally, here is my question.  Is this restriction necessary, or could it 
be eventually removed?  Just wondering.


-- 
Those who fail to understand recursion are doomed to repeat it


From lists at durin42.com  Thu Apr  2 08:41:18 2015
From: lists at durin42.com (Augie Fackler)
Date: Thu, 2 Apr 2015 09:41:18 -0400
Subject: question about fold
In-Reply-To: <mfjfl4$plj$1@ger.gmane.org>
References: <mfjfl4$plj$1@ger.gmane.org>
Message-ID: <CAPLqtWK53R1LacTsQ=A2Xh5n11uf53n2erVgrwB6=ZSFf-t9HA@mail.gmail.com>

On Thu, Apr 2, 2015 at 9:19 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
> This morning I copied some of my updates from machine 1 to machine 2.
> Everything was built fine on m1, so I pulled the update to m2.  But it
> didn't build on m2.  I had forgotten to add/ci some files.  So I fixed that
> on m1 and pulled to m2.
>
> So this would seem like a perfect use for fold.  Now I have 2 different
> commits, the first says:
>
> added feature foo
>
> and 2nd says:
>
> more foo
>
> or something to that effect.
>
> But I can't use fold, because fold refused to operate on 'public' repos.
>
> So finally, here is my question.  Is this restriction necessary, or could it
> be eventually removed?  Just wondering.

This is intentional, as part of a plan to prevent accidentally
modifying history that you've published to others. If you add

[phases]
publish = false

to ~/.hgrc, then those machines won't be considered to have
"published" changes when they serve them to other clients. Does that
make sense?

(We know this is complicated and slightly annoying - improving it is
on the agenda eventually.)

For the present day problem, you can probably do 'hg phase --force
--draft' on the changes that shouldn't be marked public and then
you'll be able to edit them.

>
>
> --
> Those who fail to understand recursion are doomed to repeat it
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial

From ndbecker2 at gmail.com  Thu Apr  2 08:49:00 2015
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 02 Apr 2015 09:49 -0400
Subject: question about fold
References: <mfjfl4$plj$1@ger.gmane.org>
	<CAPLqtWK53R1LacTsQ=A2Xh5n11uf53n2erVgrwB6=ZSFf-t9HA@mail.gmail.com>
Message-ID: <mfjhcc$j3n$1@ger.gmane.org>

Augie Fackler wrote:

> On Thu, Apr 2, 2015 at 9:19 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
>> This morning I copied some of my updates from machine 1 to machine 2.
>> Everything was built fine on m1, so I pulled the update to m2.  But it
>> didn't build on m2.  I had forgotten to add/ci some files.  So I fixed
>> that on m1 and pulled to m2.
>>
>> So this would seem like a perfect use for fold.  Now I have 2 different
>> commits, the first says:
>>
>> added feature foo
>>
>> and 2nd says:
>>
>> more foo
>>
>> or something to that effect.
>>
>> But I can't use fold, because fold refused to operate on 'public' repos.
>>
>> So finally, here is my question.  Is this restriction necessary, or could
>> it
>> be eventually removed?  Just wondering.
> 
> This is intentional, as part of a plan to prevent accidentally
> modifying history that you've published to others. If you add
> 
> [phases]
> publish = false
> 
> to ~/.hgrc, then those machines won't be considered to have
> "published" changes when they serve them to other clients. Does that
> make sense?
> 

Somehow this doesn't feel all that useful to me.  For my own use, I doubt 
I'd be marking repos as experimental apriori.  I'm always ready to believe 
my changes are finished, except when I find out they're not.

> (We know this is complicated and slightly annoying - improving it is
> on the agenda eventually.)
> 
> For the present day problem, you can probably do 'hg phase --force
> --draft' on the changes that shouldn't be marked public and then
> you'll be able to edit them.
> 

And where machine2 pulls those changes, it won't complain?  For example, it 
won't care about the change in phase after having already pulled the 1st 
change, correct?


From simon at simonking.org.uk  Thu Apr  2 09:13:54 2015
From: simon at simonking.org.uk (Simon King)
Date: Thu, 2 Apr 2015 15:13:54 +0100
Subject: question about fold
In-Reply-To: <mfjhcc$j3n$1@ger.gmane.org>
References: <mfjfl4$plj$1@ger.gmane.org>
	<CAPLqtWK53R1LacTsQ=A2Xh5n11uf53n2erVgrwB6=ZSFf-t9HA@mail.gmail.com>
	<mfjhcc$j3n$1@ger.gmane.org>
Message-ID: <CAFHwexcbVUDaP_BTXg3sZoiaN2Pzhgdd0TFDTM_JxDKn8iUAkw@mail.gmail.com>

On Thu, Apr 2, 2015 at 2:49 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> Augie Fackler wrote:
>
>> On Thu, Apr 2, 2015 at 9:19 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
>>> This morning I copied some of my updates from machine 1 to machine 2.
>>> Everything was built fine on m1, so I pulled the update to m2.  But it
>>> didn't build on m2.  I had forgotten to add/ci some files.  So I fixed
>>> that on m1 and pulled to m2.
>>>
>>> So this would seem like a perfect use for fold.  Now I have 2 different
>>> commits, the first says:
>>>
>>> added feature foo
>>>
>>> and 2nd says:
>>>
>>> more foo
>>>
>>> or something to that effect.
>>>
>>> But I can't use fold, because fold refused to operate on 'public' repos.
>>>
>>> So finally, here is my question.  Is this restriction necessary, or could
>>> it
>>> be eventually removed?  Just wondering.
>>
>> This is intentional, as part of a plan to prevent accidentally
>> modifying history that you've published to others. If you add
>>
>> [phases]
>> publish = false
>>
>> to ~/.hgrc, then those machines won't be considered to have
>> "published" changes when they serve them to other clients. Does that
>> make sense?
>>
>
> Somehow this doesn't feel all that useful to me.  For my own use, I doubt
> I'd be marking repos as experimental apriori.  I'm always ready to believe
> my changes are finished, except when I find out they're not.
>
>> (We know this is complicated and slightly annoying - improving it is
>> on the agenda eventually.)
>>
>> For the present day problem, you can probably do 'hg phase --force
>> --draft' on the changes that shouldn't be marked public and then
>> you'll be able to edit them.
>>
>
> And where machine2 pulls those changes, it won't complain?  For example, it
> won't care about the change in phase after having already pulled the 1st
> change, correct?
>

machine2 won't change the phase of those changesets back to draft. As
far as I'm aware, the only way to "reduce" the phase of a changeset is
via "hg phase --force".

In fact, machine2 will still have the original 2 changesets, and it
will also get the new folded changeset, so you'll have a multi-headed
repository. This is exactly why editing history on changesets that
have been transferred to another repository is blocked by default -
there is no way for other repositories to know that a changeset has
been replaced.

The Changeset Evolution project
(http://mercurial.selenic.com/wiki/ChangesetEvolution) has added a new
facility to mercurial which will improve this in the future. With
these features enabled, when you fold 2 changesets together, the
resulting changeset will be marked as a successor of the 2 originals.
These markers are transferred between repositories on push and pull.
The end result is that when you pull on machine2, it will know that
the new folded changeset replaces the two originals.

Hope that helps,

Simon

From marc.strapetz at syntevo.com  Thu Apr  2 09:54:08 2015
From: marc.strapetz at syntevo.com (Marc Strapetz)
Date: Thu, 02 Apr 2015 16:54:08 +0200
Subject: Enriching a file log by branches, tags and bookmarks
In-Reply-To: <CABex+kiGe2zY7gmE6wf14pRy5pzJ_WEhVWPQrq7mrn9T-pP23Q@mail.gmail.com>
References: <54E1EAB9.9070205@syntevo.com>
	<CABex+kiGe2zY7gmE6wf14pRy5pzJ_WEhVWPQrq7mrn9T-pP23Q@mail.gmail.com>
Message-ID: <551D5810.3020707@syntevo.com>

Dave, sorry, I completely missed your reply.

> Are you trying to track the history of individual files, rather than the
> default of repository history?

Yes, I do.

 > hg log -f --template "{rev} {tags} {branch} {files}\n"
 > controllers/default.py

Unfortunately this does not give me the desired information. I've tried 
with setup.py from Mercurial's own repository. Here are the first lines 
of output, which do not show up any tags at all:

17926  default setup.py
17732  default .hgignore mercurial/exewrapper.c setup.py
17709  default setup.py
17606  default mercurial/parsers.c mercurial/pathencode.c setup.py
17246  stable setup.py
17121  default setup.py

And here is what I'm looking for:

http://i.imgur.com/AYt885I.png

Any more ideas?

-Marc



On 23.02.2015 19:40, Dave S wrote:
> Are you trying to track the history of individual files, rather than the
> default of repository history?
>
> You want to use templates, but I don't see a template option that gives
> just the name of the file you asked about on the command line.
>
> hg log -f --template "{rev} {tags} {branch} {files}\n"
> controllers/default.py
>
> is close, but gives you all the files changed in the applicable
> revisions.  If you drop the {files}, you don't get a file name at all
> (but you already know the filename, since you put it on the command line).
>
> An alternative would be to use the XML style:
>
> hg log -f --style xml controllers/default.py
>
>
> This doesn't seem to show the filename, either, but again you specified
> the file so you know the file.
>
> Take a look at templates in the hg help system.
>
> /dps
>
>
> On Mon, Feb 16, 2015 at 5:03 AM, Marc Strapetz
> <marc.strapetz at syntevo.com <mailto:marc.strapetz at syntevo.com>> wrote:
>
>     I'm looking for a way to enrich a file log (or sub-tree log) by
>     branches, tags and bookmarks: every such "tag" should be displayed
>     at the "closest" commit of the file log, i.e. at that commit which
>     contains the file in identical state (content). Example:
>
>     A* - B - C* - D [tag] - E*
>            \
>             F - G - H* [branch]
>
>     Let's consider the file has been changed in *-commits only, namely
>     A, C, E and H, then "branch" should be assigned to H and "tag"
>     should be assigned to C, resulting in following file log:
>
>     A - C [tag] - E
>       \
>        H [branch]
>
>     Note, that I'm not interesting in how the information is displayed,
>     any output which is reasonably parseable is fine.
>
>     As far as I understand, there is currently no such command line
>     functionality in Mercurial?
>
>     If so, is there any (high-level) API which could be used to write an
>     extension which performs this task?
>
>     If not, any ideas/suggestions how to address this problem with
>     reasonable performance? Running through the entire repository log
>     and manually shifting "tags" to those commits which are present in
>     the file/sub-tree log is my last option.
>
>     -Marc
>
>
>
>
>     _________________________________________________
>     Mercurial mailing list
>     Mercurial at selenic.com <mailto:Mercurial at selenic.com>
>     http://selenic.com/mailman/__listinfo/mercurial
>     <http://selenic.com/mailman/listinfo/mercurial>
>
>
>
>
> --
> test signature -- please apply at front gate on Tuesdays only.

From snidely.too at gmail.com  Thu Apr  2 12:33:47 2015
From: snidely.too at gmail.com (Dave S)
Date: Thu, 2 Apr 2015 10:33:47 -0700
Subject: Fwd: Enriching a file log by branches, tags and bookmarks
In-Reply-To: <CABex+kgLV8Ms-PRAOZKp4=1hLvgQPwEZ9dpC9vpVGvTrOhTjLw@mail.gmail.com>
References: <54E1EAB9.9070205@syntevo.com>
	<CABex+kiGe2zY7gmE6wf14pRy5pzJ_WEhVWPQrq7mrn9T-pP23Q@mail.gmail.com>
	<551D5810.3020707@syntevo.com>
	<CABex+kgLV8Ms-PRAOZKp4=1hLvgQPwEZ9dpC9vpVGvTrOhTjLw@mail.gmail.com>
Message-ID: <CABex+kin4xxWV-yv3xNx-GqrM71n=Rt_a_1e1ECHG+1cJngS4A@mail.gmail.com>

(Dang it, I was expecting usenet to make sure it got to the list for me)

---------- Forwarded message ----------
From: Dave S <snidely.too at gmail.com>
Date: Thu, Apr 2, 2015 at 10:32 AM
Subject: Re: Enriching a file log by branches, tags and bookmarks
To: Marc Strapetz <marc.strapetz at syntevo.com>


On Thu, Apr 2, 2015 at 7:54 AM, Marc Strapetz <marc.strapetz at syntevo.com>
wrote:

> Dave, sorry, I completely missed your reply.
>
>  Are you trying to track the history of individual files, rather than the
>> default of repository history?
>>
>
> Yes, I do.
>
> > hg log -f --template "{rev} {tags} {branch} {files}\n"
> > controllers/default.py
>
> Unfortunately this does not give me the desired information. I've tried
> with setup.py from Mercurial's own repository. Here are the first lines of
> output, which do not show up any tags at all:
>
> 17926  default setup.py
> 17732  default .hgignore mercurial/exewrapper.c setup.py
> 17709  default setup.py
> 17606  default mercurial/parsers.c mercurial/pathencode.c setup.py
> 17246  stable setup.py
> 17121  default setup.py
>
> And here is what I'm looking for:
>
> http://i.imgur.com/AYt885I.png
>
> Any more ideas?


Sorry, no, because it works for me.

57  default controllers/default.py
55  default controllers/default.py views/default/logzap.html
40 SVN4097 default controllers/default.py
39  default controllers/default.py


Note rev 40.

If you're using bookmarks instead of tags, there's another keyword you use
in the template, but I dosn't have any examples for you.

Dave
/dps




-- 
test signature -- please apply at front gate on Tuesdays only.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150402/557a2dfa/attachment.html>

From snidely.too at gmail.com  Thu Apr  2 12:51:15 2015
From: snidely.too at gmail.com (Dave S)
Date: Thu, 2 Apr 2015 10:51:15 -0700
Subject: no attribute 'islocalrepo'
Message-ID: <CABex+kjWnhs_H4uZB2vROtG8TcXN4ymWG-qHnZSWa=gxKqkBNA@mail.gmail.com>

Ok, never mind, this started as a request for help and has now turned into
a footnote.  While trying to think of what to check, I finally cleared the
extensions section of my ~/.hgrc.  I think my old hgsubversion extension
was the issue.  Since I never got the URLs right into the SVN repository, I
have no downside to blasting it away.

When I tried to play around with my command line just now, in connection
with the hg log thread, I got an exception for 'NoneType' object has no
attribute 'islocalrepo' .  I managed to get this with hg status as well.

My repos were built with 1.9 something, but I'm now running 3.3.2
(attempting to update a virtenv somehow escaped and update The Real Env).

Anyway, it looks like I sussed out what to do and life is good now, but I
thought it might be helpful to put a mention in the archives.


Dave
/dps

-- 
test signature -- please apply at front gate on Tuesdays only.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150402/7535ec71/attachment.html>

From mpm at selenic.com  Thu Apr  2 14:08:26 2015
From: mpm at selenic.com (Matt Mackall)
Date: Thu, 02 Apr 2015 14:08:26 -0500
Subject: Fwd: Enriching a file log by branches, tags and bookmarks
In-Reply-To: <CABex+kin4xxWV-yv3xNx-GqrM71n=Rt_a_1e1ECHG+1cJngS4A@mail.gmail.com>
References: <54E1EAB9.9070205@syntevo.com>
	<CABex+kiGe2zY7gmE6wf14pRy5pzJ_WEhVWPQrq7mrn9T-pP23Q@mail.gmail.com>
	<551D5810.3020707@syntevo.com>
	<CABex+kgLV8Ms-PRAOZKp4=1hLvgQPwEZ9dpC9vpVGvTrOhTjLw@mail.gmail.com>
	<CABex+kin4xxWV-yv3xNx-GqrM71n=Rt_a_1e1ECHG+1cJngS4A@mail.gmail.com>
Message-ID: <1428001706.18887.19.camel@selenic.com>

On Thu, 2015-04-02 at 10:33 -0700, Dave S wrote:
> (Dang it, I was expecting usenet to make sure it got to the list for me)
> 
> ---------- Forwarded message ----------
> From: Dave S <snidely.too at gmail.com>
> Date: Thu, Apr 2, 2015 at 10:32 AM
> Subject: Re: Enriching a file log by branches, tags and bookmarks
> To: Marc Strapetz <marc.strapetz at syntevo.com>
> 
> 
> On Thu, Apr 2, 2015 at 7:54 AM, Marc Strapetz <marc.strapetz at syntevo.com>
> wrote:
> 
> > Dave, sorry, I completely missed your reply.
> >
> >  Are you trying to track the history of individual files, rather than the
> >> default of repository history?
> >>
> >
> > Yes, I do.
> >
> > > hg log -f --template "{rev} {tags} {branch} {files}\n"
> > > controllers/default.py
> >
> > Unfortunately this does not give me the desired information. I've tried
> > with setup.py from Mercurial's own repository. Here are the first lines of
> > output, which do not show up any tags at all:
> >
> > 17926  default setup.py
> > 17732  default .hgignore mercurial/exewrapper.c setup.py
> > 17709  default setup.py
> > 17606  default mercurial/parsers.c mercurial/pathencode.c setup.py
> > 17246  stable setup.py
> > 17121  default setup.py
> >
> > And here is what I'm looking for:
> >
> > http://i.imgur.com/AYt885I.png
> >
> > Any more ideas?
> 
> 
> Sorry, no, because it works for me.
> 
> 57  default controllers/default.py
> 55  default controllers/default.py views/default/logzap.html
> 40 SVN4097 default controllers/default.py
> 39  default controllers/default.py
> 
> 
> Note rev 40.
> 
> If you're using bookmarks instead of tags, there's another keyword you use
> in the template, but I dosn't have any examples for you.

You got lucky. Original poster is apparently looking for "tags on this
revision OR any descendants of this revision that aren't otherwise
listed".

So if the file log shows revisions 1 and 10, but there's a 1.0 tag at 5,
we want to show the tag on 1 to say "this was in 1.0". Right now {tags}
will only tell you about tags on the current changeset and doesn't know
which set of changesets are going to be displayed.

So we don't in fact have a good way to do what's wanted here in a
template at present.

However, I do find this useful:

[alias]
tagged = log -r 'first($1:: and tagged())'

-- 
Mathematics is the supreme nostalgia of our time.



From marc.strapetz at syntevo.com  Fri Apr  3 08:55:51 2015
From: marc.strapetz at syntevo.com (Marc Strapetz)
Date: Fri, 03 Apr 2015 15:55:51 +0200
Subject: Fwd: Enriching a file log by branches, tags and bookmarks
In-Reply-To: <1428001706.18887.19.camel@selenic.com>
References: <54E1EAB9.9070205@syntevo.com>	<CABex+kiGe2zY7gmE6wf14pRy5pzJ_WEhVWPQrq7mrn9T-pP23Q@mail.gmail.com>	<551D5810.3020707@syntevo.com>	<CABex+kgLV8Ms-PRAOZKp4=1hLvgQPwEZ9dpC9vpVGvTrOhTjLw@mail.gmail.com>	<CABex+kin4xxWV-yv3xNx-GqrM71n=Rt_a_1e1ECHG+1cJngS4A@mail.gmail.com>
	<1428001706.18887.19.camel@selenic.com>
Message-ID: <551E9BE7.3020600@syntevo.com>

On 02.04.2015 21:08, Matt Mackall wrote:
> So if the file log shows revisions 1 and 10, but there's a 1.0 tag at 5,
> we want to show the tag on 1 to say "this was in 1.0". Right now {tags}
> will only tell you about tags on the current changeset and doesn't know
> which set of changesets are going to be displayed.
>
> So we don't in fact have a good way to do what's wanted here in a
> template at present.

I'm not necessarily looking for a template, it will also be fine if this 
could be done within a plugin. I couldn't find any high-level API which 
I could use to compose something useful here. Do you have any suggestions?

> However, I do find this useful:
>
> [alias]
> tagged = log -r 'first($1:: and tagged())'

AFAIU this gives me the most recent tag for a specific revision? I don't 
understand what happens here but could that be generalized to do what 
I'm looking for?

-Marc


From mpm at selenic.com  Fri Apr  3 10:53:51 2015
From: mpm at selenic.com (Matt Mackall)
Date: Fri, 03 Apr 2015 10:53:51 -0500
Subject: Fwd: Enriching a file log by branches, tags and bookmarks
In-Reply-To: <551E9BE7.3020600@syntevo.com>
References: <54E1EAB9.9070205@syntevo.com>
	<CABex+kiGe2zY7gmE6wf14pRy5pzJ_WEhVWPQrq7mrn9T-pP23Q@mail.gmail.com>
	<551D5810.3020707@syntevo.com>
	<CABex+kgLV8Ms-PRAOZKp4=1hLvgQPwEZ9dpC9vpVGvTrOhTjLw@mail.gmail.com>
	<CABex+kin4xxWV-yv3xNx-GqrM71n=Rt_a_1e1ECHG+1cJngS4A@mail.gmail.com>
	<1428001706.18887.19.camel@selenic.com> <551E9BE7.3020600@syntevo.com>
Message-ID: <1428076431.18887.31.camel@selenic.com>

On Fri, 2015-04-03 at 15:55 +0200, Marc Strapetz wrote:
> On 02.04.2015 21:08, Matt Mackall wrote:
> > So if the file log shows revisions 1 and 10, but there's a 1.0 tag at 5,
> > we want to show the tag on 1 to say "this was in 1.0". Right now {tags}
> > will only tell you about tags on the current changeset and doesn't know
> > which set of changesets are going to be displayed.
> >
> > So we don't in fact have a good way to do what's wanted here in a
> > template at present.
> 
> I'm not necessarily looking for a template, it will also be fine if this 
> could be done within a plugin. I couldn't find any high-level API which 
> I could use to compose something useful here. Do you have any suggestions?
>
> > However, I do find this useful:
> >
> > [alias]
> > tagged = log -r 'first($1:: and tagged())'
> 
> AFAIU this gives me the most recent tag for a specific revision? I don't 
> understand what happens here but could that be generalized to do what 
> I'm looking for?

$ hg log -r 'last(::. and file(COPYING))'
changeset:   14512:8c8b55733cbd
user:        Matt Mackall <mpm at selenic.com>
date:        Thu Jun 02 11:17:02 2011 -0500
summary:     COPYING: refresh with current address from fsf.org

The last ancestor (::) of my current working copy (.) to touch COPYING was changeset 14512.

$ hg log -r 'first(14512:: and tagged())'
changeset:   14825:de9eb6b1da4f
branch:      stable
tag:         1.9
user:        Mads Kiilerich <mads at kiilerich.com>
date:        Fri Jul 01 17:37:09 2011 +0200
summary:     util: rename the util.localpath that uses url to urllocalpath (issue2875)

The first descendant (:: on the other side) of 14512 that was tagged was 1.9 on Jul 1 2011.

$ hg tagged 14512 -T "{tags}\n"
1.9

Put it all together:

$ hg log -r 'first(last(::. and file(COPYING)):: and tagged())' -T "{tags}\n"
1.9

-- 
Mathematics is the supreme nostalgia of our time.



From snidely.too at gmail.com  Fri Apr  3 18:23:32 2015
From: snidely.too at gmail.com (Dave S)
Date: Fri, 3 Apr 2015 16:23:32 -0700
Subject: How to merge a complicated mess
In-Reply-To: <87egp9ket5.fsf@reader.local.lan>
References: <87k2z3j9yl.fsf@reader.local.lan>
	<FAC3521B-1843-4716-A3E9-A5A8EFF547FC@3gfp.com>
	<87egp9ket5.fsf@reader.local.lan>
Message-ID: <CABex+kiFxE9n9xBzT=6fiazmUP7y4nEgpFES9cncRXya1rcdiA@mail.gmail.com>

A quick thought from a third-party:

On Sat, Feb 28, 2015 at 11:37 AM, Harry Putnam <reader at newsguy.com> wrote:

> Harvey Chapman <hchapman-hg at 3gfp.com> writes:
>
> [...]
>
> Harry wrote:
>
> >> All I can think of is having to do it all by hand which sounds like
> >> a lot of time and effort.  And maybe not worth it
> [...]



>
> Harvey wrote:
>
> > Or… perhaps you need a database and not a version control system, or
> > some combination of the two.
>
> That comment zipped right over my head.  I have no practical knowledge
> of databases'.  If you have the time, can you explain in some detail
> what you mean there?
>

Each snippet would be like a "row" (record) in a [relational] database,
with a column for keywords, and a fat column for the actual text of the
note.

The DB manager would allow you to sort, search, add, delete individual
snippets.  And instead of one or more large text files to maintain, merge,
etc, you'd have a set of records.

One advantage of staying with text files and a VCS is that you would have
the history of the snippets, which would be most useful if you had to see
changes in a particular snippet.  If you are just interested in the current
"value" of a setting, than this feature isn't important.

If you want to explore the database idea, try sqlite3.  It's free, easy to
install on both Windows and Linux, and there are various ways of accessing
your data via web front-ends (which would be the equivalent of using
hgweb).  It's plenty powerful enough even if you share your snippets with a
handful of other users.

Dave
/dps


-- 
test signature -- please apply at front gate on Tuesdays only.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150403/4496c175/attachment.html>

From snidely.too at gmail.com  Fri Apr  3 18:37:38 2015
From: snidely.too at gmail.com (Dave S)
Date: Fri, 3 Apr 2015 16:37:38 -0700
Subject: How to merge a complicated mess
In-Reply-To: <87egp9ket5.fsf@reader.local.lan>
References: <87k2z3j9yl.fsf@reader.local.lan>
	<FAC3521B-1843-4716-A3E9-A5A8EFF547FC@3gfp.com>
	<87egp9ket5.fsf@reader.local.lan>
Message-ID: <CABex+khekb3J3Cqfh1YXRvCzvfVNFxv=JQAkxg=fuWi6uVot=w@mail.gmail.com>

On Sat, Feb 28, 2015 at 11:37 AM, Harry Putnam <reader at newsguy.com> wrote:

> Harvey Chapman <hchapman-hg at 3gfp.com> writes:
>
> [...]
>
> Harry wrote:
>
> >> All I can think of is having to do it all by hand which sounds like
> >> a lot of time and effort.  And maybe not worth it
>
> Harvey responded:
>
> > Try pulling them into one repo and find yourself a nice graphical
> > merge tool for your OS.
>
> I'm not sure I understand why a graphical merge tool would be good.
> I've used emacs ediff, vimdiff amd linux/unix diff.  But like I
> mentioned.. I've not done serious merging with any of them.
>
>
For your purposes, you probably just need to find what's missing in one
file that's in the alternative version, and be able to copy it from one to
the other.  If you've got formatting differences, that may be a little
trickier for the tools to deal with in a way that's any better than putting
the printouts up on the wall and going through them with a marker pen, but
sometimes you can use another tool to filter the differences out.

I'm fond of Beyond Compare, myself.  Not free, but you can try it for a
month for free, and they have a Linux version that's pretty solid.  Very
nice GUI diff program.  It will clearly identify blocks that are in
different places in the files although it may not know that those are the
same piece.  You can select to show all, show differences only, or show
orphans only.  This works in text compares and in directory compares.   For
your purposes, the 2-way compare is probably enough, but they do support
(in the Pro edition) 3-way merges.  Beyond Compare has ways to run filter
programs and is also scriptable, which isn't needed for this job.
<URL:http://www.scootersoftware.com/>

I've also used kdiff3, which is free, and works well, but I have to
re-learn it each time.

Dave
/dps

-- 
test signature -- please apply at front gate on Tuesdays only.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150403/f5d5470d/attachment.html>

From techtonik at gmail.com  Sat Apr  4 00:34:56 2015
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 4 Apr 2015 08:34:56 +0300
Subject: list all paths from tag of remote hg repository without hg binary
In-Reply-To: <CAKQoGakPUmKx3CCBcbTKfuG_qrRR+QhrG=NqWd2+m7rBWYa3VA@mail.gmail.com>
References: <CAPkN8x+8FjMVcE3A7A7rjHwTwjM-80Gnnw9cUVuMhmG4x5aKQw@mail.gmail.com>
	<19EC6BBE-933F-40F1-BC36-B373FED62246@durin42.com>
	<CAPkN8xL2VBdWnn2QYtG0PEuSfLHv9MaLwxzmAP14cszeEC-_iA@mail.gmail.com>
	<CAKQoGamufSF6azH+CFkNaN=ddJnfMjq8kvNSyyRs_iZ7sgUVXQ@mail.gmail.com>
	<CAPkN8xKFwYgH99Dkai4axyC+qfYKN_Rz-v7zc5YBr-NM2QVugA@mail.gmail.com>
	<CAKQoGakPUmKx3CCBcbTKfuG_qrRR+QhrG=NqWd2+m7rBWYa3VA@mail.gmail.com>
Message-ID: <CAPkN8xLXwQRHe8yT2H5oseNpLCquKTXEjyU6fi=P0fgDktF0=Q@mail.gmail.com>

The proposal is to have something like:
    http://localhost:8000/1.0/tags/list
and use file extension to choose the type of data to return
    http://localhost:8000/1.0/tags/list.json
    http://localhost:8000/1.0/tags/list.yaml
    http://localhost:8000/1.0/tags/list.csv

So, the list of paths will be:
    http://localhost:8000/1.0/paths/list.csv

http://www.w3.org/2013/csvw/wiki/Main_Page


On Thu, Apr 2, 2015 at 2:53 AM, Gregory Szorc <gregory.szorc at gmail.com>
wrote:

> JSON output will simply be a different "style." Just like you can prefix
> handlers with "<style>-" or add ?style= to the query string to get e.g.
> atom or rss, you'll be able to use "json."
>
> Pull @, run `hg serve` and access a URL like
> http://localhost:8000/json-tags.
>
> We certainly could add any of the gazillion REST declaration resources to
> hgweb's output. But at this point I'd like to make the API useful by
> emitting useful data. Bonus features can come later. Or they can come now.
> Patches welcome.
>
> On Tue, Mar 31, 2015 at 2:01 AM, anatoly techtonik <techtonik at gmail.com>
> wrote:
>
>> On Mon, Mar 30, 2015 at 11:44 PM, Gregory Szorc <gregory.szorc at gmail.com>
>> wrote:
>>
>>> On Mon, Mar 30, 2015 at 7:58 AM, anatoly techtonik <techtonik at gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Mon, Mar 30, 2015 at 3:41 PM, Augie Fackler <raf at durin42.com> wrote:
>>>>
>>>>>
>>>>> On Mar 30, 2015, at 7:41 AM, anatoly techtonik <techtonik at gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Hi,
>>>>> >
>>>>> > I need to get stats about files additions and removals from Python
>>>>> history. That means getting the list of all file paths for every existing
>>>>> tag. It there a way to do this remotely, without clone checkout?
>>>>> >
>>>>> > I want the tool to be a simplistic web/JS dashboard that updates
>>>>> itself automatically and doesn't run any server side binaries. Ideally I
>>>>> want to do this operation in a series of web requests:
>>>>> >
>>>>> > 1. get all tags
>>>>> > 2. for each tag get all files
>>>>> >
>>>>> > The output of `hg locate` is the ideal. Is it possible to get that
>>>>> without hg binary and for remote repository?
>>>>>
>>>>> You can screen-scrape the output of hgweb, but I’m guessing the server
>>>>> admins won’t like you much.
>>>>>
>>>>> Also, you’d be at the mercy of any HTML format changes in hgweb.
>>>>>
>>>>
>>>> Is it possible to add a REST interface to hgweb? I doubt that the
>>>> common operations will change often. As a side benefit, there will also be
>>>> a details API usage stats.
>>>>
>>>
>>> The URI space for hgweb is already RESTful. What's missing is an output
>>> format tailored for machines. "raw" is the best we have, but it isn't good
>>> enough.
>>>
>>> I started on a patch series to add a "json" style for the web interface
>>> so ?style=json or "json-<cmd>" in the URIs would produce JSON (which could
>>> be read by machines). I'd very much like to finish that work.
>>> https://hg.mozilla.org/users/gszorc_mozilla.com/hg/rev/json-style if
>>> someone wants to beat me to it.
>>>
>>> Also, the hgweb help output in @/to-be-3.4 contains detailed
>>> documentation on all the URIs and their arguments.
>>>
>>
>> Nice to know. What is the URL for that @/to-be-3.4 to look at?
>>
>> Maybe it will be better to add some integrity for REST APIs by defining a
>> dedicated URL like https://hg.python.org/cpython/rest as an endpoint for
>> both information about API and calls to it. Maybe with a link to some
>> machine readable speccy like https://apiblueprint.org/ or
>> http://raml.org/
>>
>> --
>> anatoly t.
>>
>
>


-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150404/ce81fc64/attachment.html>

From benito at benibela.de  Sat Apr  4 08:21:38 2015
From: benito at benibela.de (Benito van der Zander)
Date: Sat, 04 Apr 2015 15:21:38 +0200
Subject: .. in manifests not found / only partial clone
In-Reply-To: <1419207012.12760.10.camel@selenic.com>
References: <5494AD42.5040103@benibela.de>	
	<1419199980.12760.4.camel@selenic.com>
	<5497575C.9090409@benibela.de>
	<1419207012.12760.10.camel@selenic.com>
Message-ID: <551FE562.6070607@benibela.de>

Hi,
now I know why it could not clone that branch:

All of its commits were in the "secret" phase...


Cheers,
Benito



On 12/22/2014 01:10 AM, Matt Mackall wrote:
> On Mon, 2014-12-22 at 00:27 +0100, Benito van der Zander wrote:
>> Hi Matt,
>>
>>> Was there a proximal cause to this data loss? Power outage? Abort caused
>>> by setting +a (even though I told you it was a bad idea)?
>> Not sure
>>
>> The abort might have happened  :(
>>
>>
>>> What filesystem are you using? Ext4?
>> Still ext3
>>
>>
>>> You can ask Mercurial which revisions you need to clone thusly:
>>>
>>> $ hg log -r "heads(not 3673::)"
>> How do you clone multiple revisions?
>>
> $ hg clone -h
> hg clone [OPTION]... SOURCE [DEST]
> ...
> options ([+] can be repeated):
> ...
>   -r --rev REV [+]       include the specified changeset
>
>>> That's very odd. May be a bug. Or it may be that you've got the branch
>>> cache marked append-only and it's now corrupt because Mercurial tried to
>>> update it and silently failed.
>>>
>> The entire cache is in .hg/cache ?
>> I have only marked stuff in .hg/store/data as append only
>>
>> Perhaps it is broken from the last time, when I deleted .i files and
>> restored them
>>
>> Or because the repository did not have a "default" branch, but another
>> named branch that I renamed to default some time ago?
>>
>>>> $ hg clone -r 3217:51428989e7dc . /tmp/wtf
>>>> abort: unknown revision '3217:51428989e7dc'!
>>> The string "3217:51428989e7dc" is not a revision.
>>> It's two different forms of the name for one revision.
>>> Much of Mercurial will now accept this as a revset: the one-element
>>> range of all revisions from 3217 to 51428989e7dc.
>> One alone does not work either:
>> $ hg clone -r 3217 . /tmp/wtf
>> abort: unknown revision '3217'!
> Are you running verify/clone/branches all in the same repo?
>
> Does hg log -r 3217 work?
>
> Does hg log --hidden -r 3217 work?
>
> What hg version are you using?
>
>>> But not clone, because
>>> it can't hand a revset to a remote server.
>> It is all local.
>> Cloning from one directory to another one
> >From Mercurial's perspective, a remote repository is any repository that
> is not the one you're running the command in.
>


From marc.strapetz at syntevo.com  Tue Apr  7 08:27:41 2015
From: marc.strapetz at syntevo.com (Marc Strapetz)
Date: Tue, 07 Apr 2015 15:27:41 +0200
Subject: Fwd: Enriching a file log by branches, tags and bookmarks
In-Reply-To: <1428076431.18887.31.camel@selenic.com>
References: <54E1EAB9.9070205@syntevo.com>		<CABex+kiGe2zY7gmE6wf14pRy5pzJ_WEhVWPQrq7mrn9T-pP23Q@mail.gmail.com>		<551D5810.3020707@syntevo.com>		<CABex+kgLV8Ms-PRAOZKp4=1hLvgQPwEZ9dpC9vpVGvTrOhTjLw@mail.gmail.com>		<CABex+kin4xxWV-yv3xNx-GqrM71n=Rt_a_1e1ECHG+1cJngS4A@mail.gmail.com>	
	<1428001706.18887.19.camel@selenic.com>
	<551E9BE7.3020600@syntevo.com>
	<1428076431.18887.31.camel@selenic.com>
Message-ID: <5523DB4D.6030605@syntevo.com>

On 03.04.2015 17:53, Matt Mackall wrote:
> On Fri, 2015-04-03 at 15:55 +0200, Marc Strapetz wrote:
>> On 02.04.2015 21:08, Matt Mackall wrote:
>>> So if the file log shows revisions 1 and 10, but there's a 1.0 tag at 5,
>>> we want to show the tag on 1 to say "this was in 1.0". Right now {tags}
>>> will only tell you about tags on the current changeset and doesn't know
>>> which set of changesets are going to be displayed.
>>>
>>> So we don't in fact have a good way to do what's wanted here in a
>>> template at present.
>>
>> I'm not necessarily looking for a template, it will also be fine if this
>> could be done within a plugin. I couldn't find any high-level API which
>> I could use to compose something useful here. Do you have any suggestions?
>>
>>> However, I do find this useful:
>>>
>>> [alias]
>>> tagged = log -r 'first($1:: and tagged())'
>>
>> AFAIU this gives me the most recent tag for a specific revision? I don't
>> understand what happens here but could that be generalized to do what
>> I'm looking for?
>
> $ hg log -r 'last(::. and file(COPYING))'
> changeset:   14512:8c8b55733cbd
> user:        Matt Mackall <mpm at selenic.com>
> date:        Thu Jun 02 11:17:02 2011 -0500
> summary:     COPYING: refresh with current address from fsf.org
>
> The last ancestor (::) of my current working copy (.) to touch COPYING was changeset 14512.
>
> $ hg log -r 'first(14512:: and tagged())'
> changeset:   14825:de9eb6b1da4f
> branch:      stable
> tag:         1.9
> user:        Mads Kiilerich <mads at kiilerich.com>
> date:        Fri Jul 01 17:37:09 2011 +0200
> summary:     util: rename the util.localpath that uses url to urllocalpath (issue2875)
>
> The first descendant (:: on the other side) of 14512 that was tagged was 1.9 on Jul 1 2011.
>
> $ hg tagged 14512 -T "{tags}\n"
> 1.9
>
> Put it all together:
>
> $ hg log -r 'first(last(::. and file(COPYING)):: and tagged())' -T "{tags}\n"
> 1.9

Using revsets query, for a single tag this seems to be what I'm looking for:

$ hg log -r "max(ancestors(tagged(2.0)) and file(setup.py))" -T"{rev}\n"
15388

However, I need the iteration over all tags, so something like:

$ hg log -r "for all X in tags(): max(ancestors(tagged(X)) and 
file(setup.py))" -T "{X} {rev}\n"

AFAIU, such kind of loops are not supported by revsets, so I've 
implemented this loop outside of Mercurial, but using the command server 
API. For the Mercurial repository, file setup.py, the time required to 
get the information I'm looking for is roughly 7 seconds. That's 
acceptable. For the CPython repository, file .hgtags, it takes roughly 
50 seconds which is too slow. So looks like revsets won't solve my problem.

-Marc






From andrew at shadura.me  Fri Apr 10 12:32:14 2015
From: andrew at shadura.me (Andrew Shadura)
Date: Fri, 10 Apr 2015 19:32:14 +0200
Subject: Kallithea 0.2
Message-ID: <20150410193214.01339f26@ileemo>

Kallithea 0.2 has been released. Kallithea is a GPLv3 source code management
software for web-based hosting of Mercurial and Git repositories.

This release brings many changes since 0.1. Notably, pull requests system
have been improved, making contributing changes more robust. The visual
appearance has also been refined: modern font-based symbolic icons from
FontAwesome and GitHub Octicons have replaced the previously used bitmap
icons, and revision graphs are now drawn with HiDPI display support.
Kallithea now supports Mercurial 3.3 and Dulwich 0.9.9. Several fixes in
the database code boosted performance significantly.

We have also updated our Javascript libraries: jQuery, CodeMirror and Mergely.
Javascript and CSS code have been cleaned up, with less and less code depending
on Yahoo UI library.

Since 0.1 we have discovered two security issues, so all users are strongly
recommended to upgrade. For more details on these issues, please see our
Security Notices page: https://kallithea-scm.org/security/

For more information, see https://kallithea-scm.org/ or 
http://docs.kallithea-scm.org/

    virtualenv --no-site-packages dist/v
    . dist/v/bin/activate
    pip install kallithea
    paster make-config Kallithea my.ini
    python setup.py compile_catalog   # for translation of the UI
    paster setup-db my.ini --user=user --email=user at example.com \
      --password=password --repos=/tmp
    paster serve my.ini &
    firefox http://127.0.0.1:5000/

The summary of the changes since 0.1 release is below.

Bug fixes:

forms: add CSRF protection to all forms - CVE-2015-0276
api: don't send internal data unless asked for it - CVE-2015-0260
middleware: fix force_tls typo in force_https backward compatibility code (Issue #44)
rebranddb: update user extern_type and _name to 'internal' instead of 'kallithea' (Issue #38)
git: do not fail if git is not installed and has been removed from __init__.py BACKENDS
git: fix "'name' must be bytestring, not unicode" error on browsing changesets
git: close SubprocessIOChunker inputstream used for git (Issue #32)
git: introduce hack for handling git failure on --depth cloning (Issue #33)
git: fix version detection with unexpected version string (Issue #71)
git: preserve line endings when calling out to git
hg: fix clone from svn+http urls using hg-svn (Issue #72)
migrate: add missing import (Issue #29)
pullrequests: handle pull requests to empty repos (Issue #27)
pullrequests: when creating PRs, fix handling of new ajax requests while other ajax requests are pending
pullrequests: fix updates for PRs between different repositories
pullrequests: preserve query parameters in pull request overview paging links
compare: workaround unexpected Mercurial behaviour when finding ancestor of null rev
javascript: remove trailing comma to please IE8 (Issue #39)
download: fix for zip file downloads not being valid zips (Issue #35)
helpers: fix crash on new users without email (Issue #28)
middleware: change middleware ordering so we don't buffer hgweb output in redirect
bin: give kallithea_config.py #!/usr/bin/env python so it can be executed directly
bin: reintroduce cleanup-repos paster command
bin: fix update_repoinfo command
urlify: don't include trailing punctuation in markup
urlify: markup of hashes in ()
styling: don't loop on trying to load kallithea-logo.png after kallithea-logo.svg failed
error: don't crash on /error/document urls
error: don't crash on response without status
admin: prevent deletion of users that are owners of a repository/user group (Issue #64)
admin: make settings hook name field smaller so it is less likely to overlap with the value field
admin: when scanning for repos to add, ignore removed groups
auth_crowd: fix Admin Group Membership when using the Atlassian Crowd plugin
auth: enable selecting PAM authentication module
auth_ldap: fix user automatically activated with LDAP authentication (Issue #78)
db: fix beaker cache key for user groups - don't collide with users
db: fix handling of (invalid) unicode email addresses
db: don't use sql 'in' on empty sets in compare - avoid warning of bad performance
db: to the extent it makes sense to have a one byte size limit, make it 255 instead of 256 to please MySQL (Issue #96)
files: use current revision as default for 'show at' (Issue #31)
files: fix HTML injection via file names
files: use forward slash as path separator for consistency
files: don't use HTML encoding where not needed (closes: #74).
feed: urlify and escape the commit description
diff: fix diff of renamed files with whitespace in their names
diff: don't split lines on bare CR as python splitlines do
mergely: update Mergely to v3.3.9 (Issue #83)
jquery: upgrade to 1.11.1
codemirror: cleanup of integration and update to version 4.7
setup: constrain dulwich to version 0.9.9, fixes CVE-2015-0838
gists: add missing formencode.htmlfill import
ini: Make celeryd.log.level default values uppercase - lowercase might not be recognized and cause failure
notification: handle unicode translations (Issue #95)
repos: fix redirect after repo creation (and user/group add focus) (Issue #98)
changeset: don't crash on malformed whitespace parameter - return 400 Bad Request
stats: fix display when no data ready yet
stats: fix "show more" link


Features and improvements:

ui: use font based icons - FontAwesome and Git Hub Octicons from fontello
ui: HiDPI / Retina support in graphs and other places
paster: add install-iis command to automate IIS handler generation and update documentation
email templates: send text/plain part as well
docs: lots of improvements of structure and content and language
translations: updated using WebLate
admin: show links to added repos after repo scan
admin: show links to created users and groups
admin: when scanning for repos without 'remove', report the repos that could/would be removed
setup: support Mercurial 3.3
db: drop most lazy joins - significant performance improvement
db: add missing indices - significant performance improvement
db: don't commit session if cache invalidation didn't change anything - improves performance
comment: show full username in emails for PR/changeset comments
changelog: added Settings to repo context menu
utils: better display of ages >1 year when in short form
remotes: add support to clone from Mercurial repositories over ssh
hg: reimplement branch head listings more efficiently
pullrequests: use same code and table ui for Repo Pull Requests and My Pull Requests
pullrequests: add delete button to My Pull Requests overview
pullrequests: on 'my pullrequests' show the user's own vote as second column next to 'latest vote'
pullrequests: add option for adding repo owner as reviewer if none assigned
pullrequests: make top pane one big form with meta data and one save button and preview changes in pane below - more like when creating the PR
pullrequests: make 'update' functionality a separate submit button in the big form, automatically enabled when an update changeset is chosen
pullrequests: show graph next to the list of changesets that are available for update
pullrequests: for available changesets, also show changesets that not are descendants and thus not directly available but will be merged in
pullrequests: show unrelated branch heads in the graph too - show the problem instead of trying to explain it
pullrequests: show pending reviewer changes with "(not saved)"
pullrequests: show comment count in top of summary box
diff: improved parsing, be more strict and fail with good error messages
diff: handle GIT delta binary patches
diff: show renamed files as that
diff: make trailing spaces more visible - make vertical line less transparent
diff: show CR (\r) in diffs
comment: warn before leaving page with open comments
comment: clarify shown comment count (inline vs general)
comment: extend next/previous links to global comments (issue #91)



Changes (might influence workflows):

i18n: en translation has been removed - make sure to update your .ini files to have 'lang =' (nothing)
ini: turn show_revision_number off by default
pullrequests: don't give changeset 'unreviewed' status just because it is added to a PR
pullrequests: tweak readable titles - just append /_/ and branch name
pullrequests: only author and admin can close
pullrequests: don't add repo owner as reviewer in all PRs
pullrequests: PRs between different repos should default to same destination/source branch
pullrequests: use '-- ' as separator in the automatic text when "updating" pull requests and is it to put latest updates first
diff: don't group diffs based on the kind of change
admin: set current user as owner when running repo scan
changelog: change default view to 100 changesets, max to 2000
date representation: use ISO8601 rather than a specific locale
user groups: drop add/remove all buttons for member selection - they are too dangerous and multi-select can do the same
hg: drop support for hg web.hidden
template: link the last revision in the file browser to the changeset


Cleanup:

code: Fix typos and language in comments and code
ui: Correct capitalization and improved English text in the UI
javascript: use strict mode
tags: rename old non-Kallithea tags and prefix them with 0.0 to show that Kallithea is superior
javascript: more jQuery, less YUI, less clutter
templates: better structure, less cut'n'paste coding
html: various improvements
css: various improvements
exceptions: avoid silently catching exceptions - especially avoid catch all
tests: stability fixes
tests: remove large unused test fixture
whitespacecleanup.sh: run it regularly to ensure consistent whitespace and avoid spurious changes
controllers: consistently use formfill.render with force_defaults=False
gists: use allow_extra_fields and filter_extra_fields in gist forms like in most other forms
json: always use kallithea.lib.compat for json - and nothing else
json: drop simplejson fallback and just use stdlib
db: check for None instead of boolean false if that is what we mean

-- 
Cheers,
  Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://selenic.com/pipermail/mercurial/attachments/20150410/ba7373b0/attachment.pgp>

From lasse at lassekliemann.de  Sat Apr 11 05:23:17 2015
From: lasse at lassekliemann.de (Lasse Kliemann)
Date: Sat, 11 Apr 2015 10:23:17 +0000 (UTC)
Subject: tell update to run only if there are no conflicts
Message-ID: <loom.20150411T115936-353@post.gmane.org>

Suppose I have changed some files in my working copy, then run

hg pull
hg update

and the incoming changesets do not concern the files that I have changed,
those are simply updated in the working copy, and my new parent will be the
last changeset that I pulled in (not considering multiple branches now,
which might make it more complicated, I haven't thought about that yet).


This workflow, in my opinion, gives a much cleaner, more linear history than
first commiting, then pulling and merging. It also works when the pulled in
changes concern the files that I was editing, provided that the changes can
be merged.

However, if there are conflicts, the process is stuck until those conflicts
are resolved. In this case, I think that first commiting and then merging
and resolving the conflict is the cleaner version.

Is there a way to tell the update command to only do something if that does
not cause any conflicts?

Part of the background of my question is that I'm looking for a command
sequence that unexperienced users (who might never have heard of a "merge"
or something like that) can always use and which will never get their
working copy stuck in some way. Currently, a working sequence is:

hg commit
hg push -f
hg pull
hg update

This will always complete and make the user's changes known to the central
repository (where the push is to), probably be creating a new head, so that
I or anyone else on the team who is more experienced can see what the user
did and also do merges, resolve conflicts, etc.

(For my applications, this is one of *the* reasons why we prefer Mercurial
before anything else, because Mercurial is the only system I know of where
such a sequence exists. Git, for example, cannot do it, at least not without
certain add-ons, which still have to be written. I recently discussed that
on the Git mailing list.)

A drawback is still that we get that highly non-linear history. So I would
prefer:

hg pull
hg update --only-if-no-conflicts
hg commit
hg push -f

Is that possible or would it be possible to implement?

Thanks a lot!


From mharbison72 at gmail.com  Sat Apr 11 12:20:34 2015
From: mharbison72 at gmail.com (Matt Harbison)
Date: Sat, 11 Apr 2015 13:20:34 -0400
Subject: tell update to run only if there are no conflicts
In-Reply-To: <loom.20150411T115936-353@post.gmane.org>
References: <loom.20150411T115936-353@post.gmane.org>
Message-ID: <op.xwxugkx59lwrgf@envy>

On Sat, 11 Apr 2015 06:23:17 -0400, Lasse Kliemann  
<lasse at lassekliemann.de> wrote:

> Suppose I have changed some files in my working copy, then run
>
> hg pull
> hg update
>
> and the incoming changesets do not concern the files that I have changed,
> those are simply updated in the working copy, and my new parent will be  
> the
> last changeset that I pulled in (not considering multiple branches now,
> which might make it more complicated, I haven't thought about that yet).
>
>
> This workflow, in my opinion, gives a much cleaner, more linear history  
> than
> first commiting, then pulling and merging. It also works when the pulled  
> in
> changes concern the files that I was editing, provided that the changes  
> can
> be merged.
>
> However, if there are conflicts, the process is stuck until those  
> conflicts
> are resolved. In this case, I think that first commiting and then merging
> and resolving the conflict is the cleaner version.
>
> Is there a way to tell the update command to only do something if that  
> does
> not cause any conflicts?
>
> Part of the background of my question is that I'm looking for a command
> sequence that unexperienced users (who might never have heard of a  
> "merge"
> or something like that) can always use and which will never get their
> working copy stuck in some way. Currently, a working sequence is:
>
> hg commit
> hg push -f
> hg pull
> hg update
>
> This will always complete and make the user's changes known to the  
> central
> repository (where the push is to), probably be creating a new head, so  
> that
> I or anyone else on the team who is more experienced can see what the  
> user
> did and also do merges, resolve conflicts, etc.
>
> (For my applications, this is one of *the* reasons why we prefer  
> Mercurial
> before anything else, because Mercurial is the only system I know of  
> where
> such a sequence exists. Git, for example, cannot do it, at least not  
> without
> certain add-ons, which still have to be written. I recently discussed  
> that
> on the Git mailing list.)
>
> A drawback is still that we get that highly non-linear history. So I  
> would
> prefer:
>
> hg pull
> hg update --only-if-no-conflicts
> hg commit
> hg push -f
>
> Is that possible or would it be possible to implement?

You might want to follow this:

   http://bz.selenic.com/show_bug.cgi?id=4404


Someone posted an alias called "restore" a few years back on one of the  
mailing lists, which would get the uncommitted files back to their  
original state after the update stopped with conflicts.  I have it  
bookmarked at work, but I can't find it now.


In the meantime, I think you can get a pretty good idea if there will be  
any conflicts with:

	$ hg status --rev .::  # changes between working dir parent and pulled tip

and seeing if any of the files are also named in

	$ hg status  # your changes

This should work even if you pull in unrelated branches.  (Try it first- I  
didn't have incoming on any repos I'm tracking).

--Matt

From voldermort at hotmail.com  Sun Apr 12 04:22:44 2015
From: voldermort at hotmail.com (Harry .)
Date: Sun, 12 Apr 2015 09:22:44 +0000
Subject: cannot unshelve after shelve
Message-ID: <DUB123-W19FB985D9EAFDE70CC65F2CDF80@phx.gbl>

I ran hg shelve with modified and new/removed files. The command succeeded, but I cannot unshelve, because the new files mark the working dir as dirty.

- Is there any easy way out of this? I want to unshelve, or add the new/removed files to the shelve.
- Shouldn't shelve have at least warned that I wouldn't be able to unshelve?
 		 	   		  

From kastner-masilko at at.festo.com  Mon Apr 13 02:48:08 2015
From: kastner-masilko at at.festo.com (Kastner Masilko, Friedrich)
Date: Mon, 13 Apr 2015 07:48:08 +0000
Subject: tell update to run only if there are no conflicts
In-Reply-To: <loom.20150411T115936-353@post.gmane.org>
References: <loom.20150411T115936-353@post.gmane.org>
Message-ID: <69F9A29923FDEC41BA825ABEF83487CCBD4B3543@SDET3287.de.festo.net>

> From: Mercurial [mailto:mercurial-bounces at selenic.com] On Behalf Of Lasse Kliemann
>
> So I would prefer:
> 
> hg pull
> hg update --only-if-no-conflicts
> hg commit
> hg push -f
> 
> Is that possible or would it be possible to implement?

What should happen between the second and third line when a conflict arises? Auto-commit and merge triggering, so your third line will commit the merge? Or simply revert cleanly and restore, so your third line will commit the new head?



Development Engineering Software Suite
Festo Gesellschaft m.b.H.
Linzer Strasse 227
Austria - 1140 Wien

Firmenbuch Wien
FN 38435y
UID: ATU14650108

Tel: +43(1)91075-198
Fax: +43(1)91075-282
www.festo.at

Der Inhalt dieser E-Mail und moeglicher Anhaenge sind ausschliesslich fuer den bezeichneten Adressaten bestimmt.
Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail und
moeglicher Anhaenge durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender der E-Mail in
Verbindung zu setzen, falls Sie nicht der Adressat dieser E-Mail sind sowie das Material von Ihrem Computer zu loeschen.

This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or
dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this
e-mail, please delete it and immediately notify the sender.


From lasse at lassekliemann.de  Mon Apr 13 04:22:56 2015
From: lasse at lassekliemann.de (Lasse Kliemann)
Date: Mon, 13 Apr 2015 11:22:56 +0200
Subject: tell update to run only if there are no conflicts
In-Reply-To: <69F9A29923FDEC41BA825ABEF83487CCBD4B3543@SDET3287.de.festo.net>
References: <loom.20150411T115936-353@post.gmane.org>
	<69F9A29923FDEC41BA825ABEF83487CCBD4B3543@SDET3287.de.festo.net>
Message-ID: <ygea8yco00f.fsf@lassekliemann.de>

Kastner Masilko, Friedrich <kastner-masilko at at.festo.com> writes:

>> So I would prefer:
>> 
>> hg pull
>> hg update --only-if-no-conflicts
>> hg commit
>> hg push -f

> What should happen between the second and third line when a conflict
> arises? Auto-commit and merge triggering, so your third line will
> commit the merge? Or simply revert cleanly and restore, so your third
> line will commit the new head?

The second line (update) should progess as far as possbile on the path
From _parent_ to _tip_. If it has updated to changeset n on that path
and n+1 causes a conflict, then the working copy should reflect n (plus
the local changes). Then the local changes are committed by line 3.

By the way, I think this is (roughly) equivalent to first commiting and
then rebasing the new commit on changeset n.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial/attachments/20150413/f5f95595/attachment.pgp>

From fritzophrenic at gmail.com  Tue Apr 14 09:25:20 2015
From: fritzophrenic at gmail.com (Benjamin Fritz)
Date: Tue, 14 Apr 2015 09:25:20 -0500
Subject: tell update to run only if there are no conflicts
In-Reply-To: <ygea8yco00f.fsf@lassekliemann.de>
References: <loom.20150411T115936-353@post.gmane.org>
	<69F9A29923FDEC41BA825ABEF83487CCBD4B3543@SDET3287.de.festo.net>
	<ygea8yco00f.fsf@lassekliemann.de>
Message-ID: <CAMaohifrznXo1fdw3tYu0nx3MLCQDS2JX6uLxw42RBu9zVOVww@mail.gmail.com>

On Mon, Apr 13, 2015 at 4:22 AM, Lasse Kliemann <lasse at lassekliemann.de>
wrote:
>
> Kastner Masilko, Friedrich <kastner-masilko at at.festo.com> writes:
>
> >> So I would prefer:
> >>
> >> hg pull
> >> hg update --only-if-no-conflicts
> >> hg commit
> >> hg push -f
>
> > What should happen between the second and third line when a conflict
> > arises? Auto-commit and merge triggering, so your third line will
> > commit the merge? Or simply revert cleanly and restore, so your third
> > line will commit the new head?
>
> The second line (update) should progess as far as possbile on the path
> From _parent_ to _tip_. If it has updated to changeset n on that path
> and n+1 causes a conflict, then the working copy should reflect n (plus
> the local changes). Then the local changes are committed by line 3.
>
> By the way, I think this is (roughly) equivalent to first commiting and
> then rebasing the new commit on changeset n.
>

I think it would be far more predictable, with fewer chances of breaking
things, if "hg update --only-if-no-conflicts" was a no-op when conflicts
arise. Then "hg commit" would create a new head with a parent of whatever
the current working copy's parent happens to be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150414/efc93bdd/attachment.html>

From mkoconnor at gmail.com  Tue Apr 14 11:05:07 2015
From: mkoconnor at gmail.com (Michael O'Connor)
Date: Tue, 14 Apr 2015 12:05:07 -0400
Subject: Are push times linear in the size of the repo?
Message-ID: <CACaTOeaUqH9anvLWfgRFdjpCtmhCeLe7J2SfsPUyZnDdNoa_dg@mail.gmail.com>

I was looking at a breakdown of where the time was spent in pushing one
empty changeset in a repo with a few hundred thousand changesets.

It looks like there are a few places in the course of a push where some
object is created that is linear in the total size of the repo (or the
number of changesets in common between local and remote).  For example, in
determining which changesets are outgoing (see
http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/setdiscovery.py#l131),
in determining which phase information to push (see
http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/exchange.py#l144),
and in determining information about obsolescence of future heads (see
http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/discovery.py#l276).

In the third case, a patch was recently accepted to only compute this set
when the repo actually has an obsstore, but is there a plan to eventually
make pushing more incremental and not depend on the entire repo, or is it
thought that this won't be a problem?  Or perhaps I've misread the
situation?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150414/e0d08994/attachment.html>

From jwdevel at gmail.com  Tue Apr 14 11:10:44 2015
From: jwdevel at gmail.com (John W)
Date: Tue, 14 Apr 2015 09:10:44 -0700
Subject: MQ: break up a 'qrefresh'
Message-ID: <CADO30sq9kecmfFYzNzLThw7tELcNyKEUTogaZMJhH9vmG_=ssg@mail.gmail.com>

I know how to do what I want, but before I write an extension for it,
I figured I'd ask if there's some better and/or built-in way to do it.

It's a pretty simple situation:

1. You have a patch applied (call it P1), and it modifies the file 'foo'.
2. You make some updates to 'foo' and run 'qrefresh'. Now P1 is
modified (call it P1*).
3. You decide that actually, those changes should be a separate patch (P2).

How best to extract those changes to P1 into a new patch, P2?

In other words: You have P1*, and you want P1, P2

If the MQ patches have their own repo, this is doable with some
moderate shenanigans - you need to create one head with P1 and another
with P1*, do a diff between them, save that diff as P2, etc.

Is there a more straightforward way to accomplish this in Mercurial?
it seems like a fairly common occurrence, so I imagined there might be.

Thanks
-John

From gregory.szorc at gmail.com  Tue Apr 14 11:15:43 2015
From: gregory.szorc at gmail.com (Gregory Szorc)
Date: Tue, 14 Apr 2015 12:15:43 -0400
Subject: Are push times linear in the size of the repo?
In-Reply-To: <CACaTOeaUqH9anvLWfgRFdjpCtmhCeLe7J2SfsPUyZnDdNoa_dg@mail.gmail.com>
References: <CACaTOeaUqH9anvLWfgRFdjpCtmhCeLe7J2SfsPUyZnDdNoa_dg@mail.gmail.com>
Message-ID: <CAKQoGako1e1kOEc8SO2GnfwZ5JWpz_+8-xgRD_1Sbq2hPAZeQw@mail.gmail.com>

On Tue, Apr 14, 2015 at 12:05 PM, Michael O'Connor <mkoconnor at gmail.com>
wrote:

> I was looking at a breakdown of where the time was spent in pushing one
> empty changeset in a repo with a few hundred thousand changesets.
>
> It looks like there are a few places in the course of a push where some
> object is created that is linear in the total size of the repo (or the
> number of changesets in common between local and remote).  For example, in
> determining which changesets are outgoing (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/setdiscovery.py#l131),
> in determining which phase information to push (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/exchange.py#l144),
> and in determining information about obsolescence of future heads (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/discovery.py#l276).
>
> In the third case, a patch was recently accepted to only compute this set
> when the repo actually has an obsstore, but is there a plan to eventually
> make pushing more incremental and not depend on the entire repo, or is it
> thought that this won't be a problem?  Or perhaps I've misread the
> situation?
>

In general, push times (ignoring the size of the data being exchanged) are
tied stronger to the number of DAG heads than the number of commits in a
repository. A repository with 200,000 commits and 100,000 heads will likely
take longer to push to than a repository with 10,000,000 commits and 10
heads.

There is room to optimize discovery on repos with thousands of heads. This
is a problem Mozilla has and fixing it in core and by extensions has been
discussed before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150414/485b83e6/attachment.html>

From greg at gerg.ca  Sat Apr 11 12:54:35 2015
From: greg at gerg.ca (Greg Ward)
Date: Sat, 11 Apr 2015 13:54:35 -0400
Subject: tell update to run only if there are no conflicts
In-Reply-To: <loom.20150411T115936-353@post.gmane.org>
References: <loom.20150411T115936-353@post.gmane.org>
Message-ID: <20150411175434.GA15433@renesys.com>

On 11 April 2015, Lasse Kliemann said:
> Suppose I have changed some files in my working copy, then run
> 
> hg pull
> hg update
> 
> and the incoming changesets do not concern the files that I have changed,
> those are simply updated in the working copy, and my new parent will be the
> last changeset that I pulled in (not considering multiple branches now,
> which might make it more complicated, I haven't thought about that yet).

Note that you can still have conflicts in such a case: say the
incoming changesets add a required argument to an existing method and
update all existing callers. Your local change adds an additional call
site. Even though there is no *textual* conflict (within a file),
there's still a *semantic* conflict (across files) that must be
resolved.

IOW: if you have uncommitted changes, update *is* a merge, even for
users who don't know what "merge" means. This is equally true with CVS
and svn, FWIW.

Greg

From hchapman-hg at 3gfp.com  Tue Apr 14 11:32:03 2015
From: hchapman-hg at 3gfp.com (Harvey Chapman)
Date: Tue, 14 Apr 2015 12:32:03 -0400
Subject: MQ: break up a 'qrefresh'
In-Reply-To: <CADO30sq9kecmfFYzNzLThw7tELcNyKEUTogaZMJhH9vmG_=ssg@mail.gmail.com>
References: <CADO30sq9kecmfFYzNzLThw7tELcNyKEUTogaZMJhH9vmG_=ssg@mail.gmail.com>
Message-ID: <6EDACC65-9FDB-4FF8-8A24-0542E9297B06@3gfp.com>


> On Apr 14, 2015, at 12:10 PM, John W <jwdevel at gmail.com> wrote:
> 
> I know how to do what I want, but before I write an extension for it,
> I figured I'd ask if there's some better and/or built-in way to do it.
> 
> It's a pretty simple situation:
> 
> 1. You have a patch applied (call it P1), and it modifies the file 'foo'.
> 2. You make some updates to 'foo' and run 'qrefresh'. Now P1 is
> modified (call it P1*).
> 3. You decide that actually, those changes should be a separate patch (P2).
> 
> How best to extract those changes to P1 into a new patch, P2?
> 
> In other words: You have P1*, and you want P1, P2
> 
> If the MQ patches have their own repo, this is doable with some
> moderate shenanigans - you need to create one head with P1 and another
> with P1*, do a diff between them, save that diff as P2, etc.
> 
> Is there a more straightforward way to accomplish this in Mercurial?
> it seems like a fairly common occurrence, so I imagined there might be.

"hg qrefresh —interactive” will probably work unless your changes are close together.


From hchapman-hg at 3gfp.com  Tue Apr 14 11:36:56 2015
From: hchapman-hg at 3gfp.com (Harvey Chapman)
Date: Tue, 14 Apr 2015 12:36:56 -0400
Subject: MQ: break up a 'qrefresh'
In-Reply-To: <6EDACC65-9FDB-4FF8-8A24-0542E9297B06@3gfp.com>
References: <CADO30sq9kecmfFYzNzLThw7tELcNyKEUTogaZMJhH9vmG_=ssg@mail.gmail.com>
	<6EDACC65-9FDB-4FF8-8A24-0542E9297B06@3gfp.com>
Message-ID: <1AB2901D-0FB6-4158-B3B7-116E2975A16D@3gfp.com>


> On Apr 14, 2015, at 12:32 PM, Harvey Chapman <hchapman-hg at 3gfp.com> wrote:
> 
> 
>> On Apr 14, 2015, at 12:10 PM, John W <jwdevel at gmail.com> wrote:
>> 
>> I know how to do what I want, but before I write an extension for it,
>> I figured I'd ask if there's some better and/or built-in way to do it.
>> 
>> It's a pretty simple situation:
>> 
>> 1. You have a patch applied (call it P1), and it modifies the file 'foo'.
>> 2. You make some updates to 'foo' and run 'qrefresh'. Now P1 is
>> modified (call it P1*).
>> 3. You decide that actually, those changes should be a separate patch (P2).
>> 
>> How best to extract those changes to P1 into a new patch, P2?
>> 
>> In other words: You have P1*, and you want P1, P2
>> 
>> If the MQ patches have their own repo, this is doable with some
>> moderate shenanigans - you need to create one head with P1 and another
>> with P1*, do a diff between them, save that diff as P2, etc.
>> 
>> Is there a more straightforward way to accomplish this in Mercurial?
>> it seems like a fairly common occurrence, so I imagined there might be.
> 
> "hg qrefresh —interactive” will probably work unless your changes are close together.

I had to remove the file from the patch first:

    hg qrefresh -X file
    hg qrefresh -s -i file

From jwdevel at gmail.com  Tue Apr 14 12:06:11 2015
From: jwdevel at gmail.com (John W)
Date: Tue, 14 Apr 2015 10:06:11 -0700
Subject: MQ: break up a 'qrefresh'
In-Reply-To: <1AB2901D-0FB6-4158-B3B7-116E2975A16D@3gfp.com>
References: <CADO30sq9kecmfFYzNzLThw7tELcNyKEUTogaZMJhH9vmG_=ssg@mail.gmail.com>
	<6EDACC65-9FDB-4FF8-8A24-0542E9297B06@3gfp.com>
	<1AB2901D-0FB6-4158-B3B7-116E2975A16D@3gfp.com>
Message-ID: <CADO30spPLVTAbUHHSVLC0eNc8ikDT9LQAF+nJgpjj_5Kt=4+qg@mail.gmail.com>

Yes, that is not terrible in the 80% case.

I'm trying to avoid manual interactivity if possible, and ideally
doing something that works for a totally general case.

I'm pretty sure this *is* possible to solve generally — all the
information is there. It's just cumbersome, every way I can think
of...

-John

On 4/14/15, Harvey Chapman <hchapman-hg at 3gfp.com> wrote:
>
>> On Apr 14, 2015, at 12:32 PM, Harvey Chapman <hchapman-hg at 3gfp.com>
>> wrote:
>>
>>
>>> On Apr 14, 2015, at 12:10 PM, John W <jwdevel at gmail.com> wrote:
>>>
>>> I know how to do what I want, but before I write an extension for it,
>>> I figured I'd ask if there's some better and/or built-in way to do it.
>>>
>>> It's a pretty simple situation:
>>>
>>> 1. You have a patch applied (call it P1), and it modifies the file
>>> 'foo'.
>>> 2. You make some updates to 'foo' and run 'qrefresh'. Now P1 is
>>> modified (call it P1*).
>>> 3. You decide that actually, those changes should be a separate patch
>>> (P2).
>>>
>>> How best to extract those changes to P1 into a new patch, P2?
>>>
>>> In other words: You have P1*, and you want P1, P2
>>>
>>> If the MQ patches have their own repo, this is doable with some
>>> moderate shenanigans - you need to create one head with P1 and another
>>> with P1*, do a diff between them, save that diff as P2, etc.
>>>
>>> Is there a more straightforward way to accomplish this in Mercurial?
>>> it seems like a fairly common occurrence, so I imagined there might be.
>>
>> "hg qrefresh —interactive” will probably work unless your changes are
>> close together.
>
> I had to remove the file from the patch first:
>
>     hg qrefresh -X file
>     hg qrefresh -s -i file

From mkoconnor at gmail.com  Tue Apr 14 13:35:42 2015
From: mkoconnor at gmail.com (Michael O'Connor)
Date: Tue, 14 Apr 2015 14:35:42 -0400
Subject: Are push times linear in the size of the repo?
In-Reply-To: <CAKQoGako1e1kOEc8SO2GnfwZ5JWpz_+8-xgRD_1Sbq2hPAZeQw@mail.gmail.com>
References: <CACaTOeaUqH9anvLWfgRFdjpCtmhCeLe7J2SfsPUyZnDdNoa_dg@mail.gmail.com>
	<CAKQoGako1e1kOEc8SO2GnfwZ5JWpz_+8-xgRD_1Sbq2hPAZeQw@mail.gmail.com>
Message-ID: <CACaTOeZN=VdBNUpSgys5SHRzLLDC2Rz+dxqi3bQ96OhK9OhTyw@mail.gmail.com>

Got it, thanks.  I think I was wrong about the time in
setdiscovery.findcommonheads depending on the total number of changesets.
Is it the case that the performance degradation as the number of heads
increases is basically just due to the discovery algorithm?

FWIW, I think it still is straightforwardly the case that in the two other
cases I mentioned a set of all the changesets is constructed, which seems
unfortunate, although I don't have any suggestions for how to improve the
situation.

On Tue, Apr 14, 2015 at 12:15 PM, Gregory Szorc <gregory.szorc at gmail.com>
wrote:

> On Tue, Apr 14, 2015 at 12:05 PM, Michael O'Connor <mkoconnor at gmail.com>
> wrote:
>
>> I was looking at a breakdown of where the time was spent in pushing one
>> empty changeset in a repo with a few hundred thousand changesets.
>>
>> It looks like there are a few places in the course of a push where some
>> object is created that is linear in the total size of the repo (or the
>> number of changesets in common between local and remote).  For example, in
>> determining which changesets are outgoing (see
>> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/setdiscovery.py#l131),
>> in determining which phase information to push (see
>> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/exchange.py#l144),
>> and in determining information about obsolescence of future heads (see
>> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/discovery.py#l276
>> ).
>>
>> In the third case, a patch was recently accepted to only compute this set
>> when the repo actually has an obsstore, but is there a plan to eventually
>> make pushing more incremental and not depend on the entire repo, or is it
>> thought that this won't be a problem?  Or perhaps I've misread the
>> situation?
>>
>
> In general, push times (ignoring the size of the data being exchanged) are
> tied stronger to the number of DAG heads than the number of commits in a
> repository. A repository with 200,000 commits and 100,000 heads will likely
> take longer to push to than a repository with 10,000,000 commits and 10
> heads.
>
> There is room to optimize discovery on repos with thousands of heads. This
> is a problem Mozilla has and fixing it in core and by extensions has been
> discussed before.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150414/41d8a62a/attachment.html>

From mpm at selenic.com  Tue Apr 14 13:42:42 2015
From: mpm at selenic.com (Matt Mackall)
Date: Tue, 14 Apr 2015 14:42:42 -0400
Subject: cannot unshelve after shelve
In-Reply-To: <DUB123-W19FB985D9EAFDE70CC65F2CDF80@phx.gbl>
References: <DUB123-W19FB985D9EAFDE70CC65F2CDF80@phx.gbl>
Message-ID: <1429036962.32745.15.camel@selenic.com>

On Sun, 2015-04-12 at 09:22 +0000, Harry . wrote:
> I ran hg shelve with modified and new/removed files. The command succeeded, but I cannot unshelve, because the new files mark the working dir as dirty.

BTS, please.

-- 
Mathematics is the supreme nostalgia of our time.



From pierre-yves.david at ens-lyon.org  Tue Apr 14 23:16:17 2015
From: pierre-yves.david at ens-lyon.org (Pierre-Yves David)
Date: Wed, 15 Apr 2015 00:16:17 -0400
Subject: Are push times linear in the size of the repo?
In-Reply-To: <CACaTOeaUqH9anvLWfgRFdjpCtmhCeLe7J2SfsPUyZnDdNoa_dg@mail.gmail.com>
References: <CACaTOeaUqH9anvLWfgRFdjpCtmhCeLe7J2SfsPUyZnDdNoa_dg@mail.gmail.com>
Message-ID: <552DE611.4080101@ens-lyon.org>



On 04/14/2015 12:05 PM, Michael O'Connor wrote:
> I was looking at a breakdown of where the time was spent in pushing one
> empty changeset in a repo with a few hundred thousand changesets.
>
> It looks like there are a few places in the course of a push where some
> object is created that is linear in the total size of the repo (or the
> number of changesets in common between local and remote).  For example,
> in determining which changesets are outgoing (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/setdiscovery.py#l131),
> in determining which phase information to push (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/exchange.py#l144), and
> in determining information about obsolescence of future heads (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/discovery.py#l276).
>
> In the third case, a patch was recently accepted to only compute this
> set when the repo actually has an obsstore, but is there a plan to
> eventually make pushing more incremental and not depend on the entire
> repo, or is it thought that this won't be a problem?  Or perhaps I've
> misread the situation?

Nothing should be have a linear time, current situation with many small 
branches all unknown on one side will increase the number of round trip.

Obsolescence discovery and pushing are currently suboptimal. This is one 
of the reason why evolution is still experimental. There is concret plan 
to improve that to a point where is quick at any size.

-- 
Pierre-Yves David

From Charlie at TheGallos.com  Wed Apr 15 18:28:28 2015
From: Charlie at TheGallos.com (Charlie Gallo)
Date: Wed, 15 Apr 2015 19:28:28 -0400
Subject: State of Hg-SVN vs Git-SVN
Message-ID: <5110525565.20150415192828@TheGallos.com>

Hi Gang,
I'm in an "Interesting" position.

I'm  about  to  start  a  new  role where I'm going to get to make the
technology decisions for the future team.

Right  now, the existing source control system is SVN, and for various
political  reasons,  I  don't think it would be a good idea to make an
IMMEDIATE  jump to Hg or GIT - but as I will be working remote a large
percentage of the time, having a DSCS is a big deal for me

My plan is to either use Hg-SVN or GIT-SVN

Here is my problem - deciding which

It  has  been  a long time since I've used Hg-SVN, and I've never used
GIT-SVN.

I prefer Hg to Git, (fits the way I work better) BUT, and it is a huge
but, with Microsoft's support of Git inside Visual Studio 2013 and
later  (and  TFS - which I don't love) there are some strong points to
be made for Git (basically, making it easier/Microsoft's 'support')

Anyone  on  the  group  have experience with both?  Pros/cons.  One of
those times where I have to look at a bigger picture than just which I
like  better (Hg) and have to look at "which is better for the company
in the long run"
-- 
Charlie
www.baysidephoto.com
www.thegallos.com


From bmurdock at gmail.com  Wed Apr 15 23:47:33 2015
From: bmurdock at gmail.com (Bryan Murdock)
Date: Wed, 15 Apr 2015 22:47:33 -0600
Subject: State of Hg-SVN vs Git-SVN
In-Reply-To: <5110525565.20150415192828@TheGallos.com>
References: <5110525565.20150415192828@TheGallos.com>
Message-ID: <CAPY2A7N0QK=Y1DAat6KceCMJ3=cA9_LQo3AdO10j3J7aU6oUzA@mail.gmail.com>

On Wed, Apr 15, 2015 at 5:28 PM, Charlie Gallo <Charlie at thegallos.com> wrote:
> Hi Gang,
> I'm in an "Interesting" position.
>
> I'm  about  to  start  a  new  role where I'm going to get to make the
> technology decisions for the future team.
>
> Right  now, the existing source control system is SVN, and for various
> political  reasons,  I  don't think it would be a good idea to make an
> IMMEDIATE  jump to Hg or GIT - but as I will be working remote a large
> percentage of the time, having a DSCS is a big deal for me
>
> My plan is to either use Hg-SVN or GIT-SVN
>
> Here is my problem - deciding which
>
> It  has  been  a long time since I've used Hg-SVN, and I've never used
> GIT-SVN.
>
> I prefer Hg to Git, (fits the way I work better) BUT, and it is a huge
> but, with Microsoft's support of Git inside Visual Studio 2013 and
> later  (and  TFS - which I don't love) there are some strong points to
> be made for Git (basically, making it easier/Microsoft's 'support')
>
> Anyone  on  the  group  have experience with both?  Pros/cons.  One of
> those times where I have to look at a bigger picture than just which I
> like  better (Hg) and have to look at "which is better for the company
> in the long run"

I was recently forced to use svn and so I have been using hgsbuversion
in order to cope.  It works fairly well, depending on your svn setup
and needs.  The svn repo I'm using has svn:externals defined and that
gives hgsubversion a hard time.  From what I read, however, git-svn
doesn't support externals at all (but a number of people have written
some scripts to deal with that shortcoming).  For hgsubversion I found
the best solution was to *not* tell it to use subrepos and to remember
to always run hg svn updateexternals after every hg update (or
equivalent) command.  Subversion supports relative paths to externals
but hgsubversion seems to only understand fully-qualified paths, not
relative paths.

Other than the externals caveats, hgsubversion has no support for svn
tags (maybe because they aren't really tags?) and it cannot merge svn
branches (can anything?  I kid...).  I don't know if git-svn does
better with those two things.

The last thing to be aware of is that you are required to rebase your
local commits on top of others svn commits before you can push, to
keep a linear svn-accommodating history.  Again, I don't know how
git-svn works in this regard, but it's hard to image it working any
other way.

One really interesting thing is that your hgsbuversion clone (which,
remember, contains the whole repository history) will probably be
smaller in size than your svn working copy.  Apparently svn keeps a
large amount of metadata in that working copy.  Sorry, don't know
about git-svn on this issue either.

Bryan

From steve at borho.org  Thu Apr 16 01:28:01 2015
From: steve at borho.org (Steve Borho)
Date: Wed, 15 Apr 2015 23:28:01 -0700
Subject: State of Hg-SVN vs Git-SVN
In-Reply-To: <CAPY2A7N0QK=Y1DAat6KceCMJ3=cA9_LQo3AdO10j3J7aU6oUzA@mail.gmail.com>
References: <5110525565.20150415192828@TheGallos.com>
	<CAPY2A7N0QK=Y1DAat6KceCMJ3=cA9_LQo3AdO10j3J7aU6oUzA@mail.gmail.com>
Message-ID: <20150416062801.GN20003@borho.org>

On 04/15, Bryan Murdock wrote:
> On Wed, Apr 15, 2015 at 5:28 PM, Charlie Gallo <Charlie at thegallos.com> wrote:
> > Hi Gang,
> > I'm in an "Interesting" position.
> >
> > I'm  about  to  start  a  new  role where I'm going to get to make the
> > technology decisions for the future team.
> >
> > Right  now, the existing source control system is SVN, and for various
> > political  reasons,  I  don't think it would be a good idea to make an
> > IMMEDIATE  jump to Hg or GIT - but as I will be working remote a large
> > percentage of the time, having a DSCS is a big deal for me
> >
> > My plan is to either use Hg-SVN or GIT-SVN
> >
> > Here is my problem - deciding which
> >
> > It  has  been  a long time since I've used Hg-SVN, and I've never used
> > GIT-SVN.
> >
> > I prefer Hg to Git, (fits the way I work better) BUT, and it is a huge
> > but, with Microsoft's support of Git inside Visual Studio 2013 and
> > later  (and  TFS - which I don't love) there are some strong points to
> > be made for Git (basically, making it easier/Microsoft's 'support')

not to toot our own horn too much, but my company has recently announced
a new plugin for VisualStudio for Mercurial which aims to plug this gap
long term. The plugin is GPL but has a small cost per developer to cover
development and maintenance.

https://hgvs.multicorewareinc.com/

> > Anyone  on  the  group  have experience with both?  Pros/cons.  One of
> > those times where I have to look at a bigger picture than just which I
> > like  better (Hg) and have to look at "which is better for the company
> > in the long run"
> 
> I was recently forced to use svn and so I have been using hgsbuversion
> in order to cope.  It works fairly well, depending on your svn setup
> and needs.  The svn repo I'm using has svn:externals defined and that
> gives hgsubversion a hard time.  From what I read, however, git-svn
> doesn't support externals at all (but a number of people have written
> some scripts to deal with that shortcoming).  For hgsubversion I found
> the best solution was to *not* tell it to use subrepos and to remember
> to always run hg svn updateexternals after every hg update (or
> equivalent) command.  Subversion supports relative paths to externals
> but hgsubversion seems to only understand fully-qualified paths, not
> relative paths.
> 
> Other than the externals caveats, hgsubversion has no support for svn
> tags (maybe because they aren't really tags?) and it cannot merge svn
> branches (can anything?  I kid...).  I don't know if git-svn does
> better with those two things.
> 
> The last thing to be aware of is that you are required to rebase your
> local commits on top of others svn commits before you can push, to
> keep a linear svn-accommodating history.  Again, I don't know how
> git-svn works in this regard, but it's hard to image it working any
> other way.
> 
> One really interesting thing is that your hgsbuversion clone (which,
> remember, contains the whole repository history) will probably be
> smaller in size than your svn working copy.  Apparently svn keeps a
> large amount of metadata in that working copy.  Sorry, don't know
> about git-svn on this issue either.

that's no metadata, svn keeps a copy of the each "working parent" file
to prevent 'svn diff' from having to talk to the server. So the working
copy is literally doubled.

-- 
Steve Borho

From wernerfbd at gmx.ch  Thu Apr 16 03:03:09 2015
From: wernerfbd at gmx.ch (Werner)
Date: Thu, 16 Apr 2015 10:03:09 +0200
Subject: State of Hg-SVN vs Git-SVN
In-Reply-To: <20150416062801.GN20003@borho.org>
References: <5110525565.20150415192828@TheGallos.com>	<CAPY2A7N0QK=Y1DAat6KceCMJ3=cA9_LQo3AdO10j3J7aU6oUzA@mail.gmail.com>
	<20150416062801.GN20003@borho.org>
Message-ID: <mgnqbr$7vs$1@ger.gmane.org>

On 4/16/2015 8:28, Steve Borho wrote:
...
> https://hgvs.multicorewareinc.com/
I get page not found on this.

Werner


From mpm at selenic.com  Thu Apr 16 09:44:42 2015
From: mpm at selenic.com (Matt Mackall)
Date: Thu, 16 Apr 2015 10:44:42 -0400
Subject: State of Hg-SVN vs Git-SVN
In-Reply-To: <5110525565.20150415192828@TheGallos.com>
References: <5110525565.20150415192828@TheGallos.com>
Message-ID: <1429195482.32745.23.camel@selenic.com>

On Wed, 2015-04-15 at 19:28 -0400, Charlie Gallo wrote:
> Hi Gang,
> I'm in an "Interesting" position.
> 
> I'm  about  to  start  a  new  role where I'm going to get to make the
> technology decisions for the future team.
> 
> Right  now, the existing source control system is SVN, and for various
> political  reasons,  I  don't think it would be a good idea to make an
> IMMEDIATE  jump to Hg or GIT - but as I will be working remote a large
> percentage of the time, having a DSCS is a big deal for me
> 
> My plan is to either use Hg-SVN or GIT-SVN
> 
> Here is my problem - deciding which
> 
> It  has  been  a long time since I've used Hg-SVN, and I've never used
> GIT-SVN.
> 
> I prefer Hg to Git, (fits the way I work better) BUT, and it is a huge
> but, with Microsoft's support of Git inside Visual Studio 2013 and
> later  (and  TFS - which I don't love) there are some strong points to
> be made for Git (basically, making it easier/Microsoft's 'support')
>
> Anyone  on  the  group  have experience with both?  Pros/cons.  One of
> those times where I have to look at a bigger picture than just which I
> like  better (Hg) and have to look at "which is better for the company
> in the long run"

FWIW, Facebook is well into the process of moving the bulk of its
development to Mercurial, having started on SVN and Git. For the
interim, there's continuous mirroring to the other two systems with
hgsubversion and hg-git, but features like remotefilelog and hgwatchman
mean that Mercurial is significantly faster so most of our users have
migrated over.

https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

(You'll note there are no absolute numbers in this post, but rest
assured that the repositories are big.)

On the Windows side of things, Mercurial integration for Visual Studio
does exist, but most users lean towards TortoiseHg. Windows support for
hgwatchman is in the pipeline.

-- 
Mathematics is the supreme nostalgia of our time.



From raf at durin42.com  Thu Apr 16 12:53:16 2015
From: raf at durin42.com (Augie Fackler)
Date: Thu, 16 Apr 2015 13:53:16 -0400
Subject: State of Hg-SVN vs Git-SVN
In-Reply-To: <CAPY2A7N0QK=Y1DAat6KceCMJ3=cA9_LQo3AdO10j3J7aU6oUzA@mail.gmail.com>
References: <5110525565.20150415192828@TheGallos.com>
	<CAPY2A7N0QK=Y1DAat6KceCMJ3=cA9_LQo3AdO10j3J7aU6oUzA@mail.gmail.com>
Message-ID: <EDCC7D9E-5214-4084-B488-0CF4753FF738@durin42.com>


On Apr 16, 2015, at 12:47 AM, Bryan Murdock <bmurdock at gmail.com> wrote:

> Other than the externals caveats, hgsubversion has no support for svn
> tags (maybe because they aren't really tags?)

FYI, this is false - hgsubversion has supported tags for at least 6 years. Some complicated setups fool it, but if you actually have a normal trunk/tags/branches setup, it should work 99% of the time. It can (for example) convert the old django repository correctly on the first try, whereas git-svn would give up on the tags.

> and it cannot merge svn
> branches (can anything?  I kid...).  I don't know if git-svn does
> better with those two things.

git-svn is slightly better on the merge story, but neither tool writes out mergeinfo, so if your team is using svn to merge, I recommend against it.

When I used to use svn, this was how I merged svn branches using hgsubversion:

https://bitbucket.org/durin42/dotfiles/src/05ccb6c5fb4b9df88e06bdc9d162912760eb554e/.shell.d/50.hg_functions.sh?at=default#cl-46

> 
> The last thing to be aware of is that you are required to rebase your
> local commits on top of others svn commits before you can push, to
> keep a linear svn-accommodating history.  Again, I don't know how
> git-svn works in this regard, but it's hard to image it working any
> other way.

git-svn works the same way in this regard.

> One really interesting thing is that your hgsbuversion clone (which,
> remember, contains the whole repository history) will probably be
> smaller in size than your svn working copy.  Apparently svn keeps a
> large amount of metadata in that working copy.  Sorry, don't know
> about git-svn on this issue either.

subversion keeps uncompressed base texts in .svn, whereas git and hg store more compact (compressed) representations of history instead of that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial/attachments/20150416/bba619a8/attachment.pgp>

From raf at durin42.com  Thu Apr 16 12:57:47 2015
From: raf at durin42.com (Augie Fackler)
Date: Thu, 16 Apr 2015 13:57:47 -0400
Subject: State of Hg-SVN vs Git-SVN
In-Reply-To: <5110525565.20150415192828@TheGallos.com>
References: <5110525565.20150415192828@TheGallos.com>
Message-ID: <E2D54F6F-8D39-41CB-951F-EDF78BA5B364@durin42.com>


On Apr 15, 2015, at 7:28 PM, Charlie Gallo <Charlie at TheGallos.com> wrote:

> Hi Gang,
> I'm in an "Interesting" position.
> 
> I'm  about  to  start  a  new  role where I'm going to get to make the
> technology decisions for the future team.
> 
> Right  now, the existing source control system is SVN, and for various
> political  reasons,  I  don't think it would be a good idea to make an
> IMMEDIATE  jump to Hg or GIT - but as I will be working remote a large
> percentage of the time, having a DSCS is a big deal for me
> 
> My plan is to either use Hg-SVN or GIT-SVN
> 
> Here is my problem - deciding which
> 
> It  has  been  a long time since I've used Hg-SVN, and I've never used
> GIT-SVN.
> 
> I prefer Hg to Git, (fits the way I work better) BUT, and it is a huge
> but, with Microsoft's support of Git inside Visual Studio 2013 and
> later  (and  TFS - which I don't love) there are some strong points to
> be made for Git (basically, making it easier/Microsoft's 'support')
> 
> Anyone  on  the  group  have experience with both?  Pros/cons.  One of
> those times where I have to look at a bigger picture than just which I
> like  better (Hg) and have to look at "which is better for the company
> in the long run”

So, I’m biased because I wrote hgsubversion, but while I was initially working on it six years ago it was a point of personal pride that I was handling complicated branching and tagging setups better than git-svn. As far as I’m aware, this is still the case[0].

Unless git-svn has gotten a ton smarter since I last looked, hgsubversion is also significantly lower-overhead on the server as well. I designed it to use almost exclusively RPCs that the Subversion server can satisfy very cheaply.


0: I recently helped an OSS project move from code.google.com’s svn to github, and the most faithful conversion ended up being subversion->hg->git, because that didn’t result in corrupt tags and missing branches. I was using a version of git from the last two months when this happened.

> -- 
> Charlie
> www.baysidephoto.com
> www.thegallos.com
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial/attachments/20150416/51739a51/attachment.pgp>

From bmurdock at gmail.com  Thu Apr 16 13:31:41 2015
From: bmurdock at gmail.com (Bryan Murdock)
Date: Thu, 16 Apr 2015 12:31:41 -0600
Subject: State of Hg-SVN vs Git-SVN
In-Reply-To: <EDCC7D9E-5214-4084-B488-0CF4753FF738@durin42.com>
References: <5110525565.20150415192828@TheGallos.com>
	<CAPY2A7N0QK=Y1DAat6KceCMJ3=cA9_LQo3AdO10j3J7aU6oUzA@mail.gmail.com>
	<EDCC7D9E-5214-4084-B488-0CF4753FF738@durin42.com>
Message-ID: <CAPY2A7M48KanmeJ3TRKhK2wpCfb41XaCxtCygSEBWaPfbh_s7Q@mail.gmail.com>

On Thu, Apr 16, 2015 at 11:53 AM, Augie Fackler <raf at durin42.com> wrote:
>
> On Apr 16, 2015, at 12:47 AM, Bryan Murdock <bmurdock at gmail.com> wrote:
>
>> Other than the externals caveats, hgsubversion has no support for svn
>> tags (maybe because they aren't really tags?)
>
> FYI, this is false - hgsubversion has supported tags for at least 6 years. Some complicated setups fool it, but if you actually have a normal trunk/tags/branches setup, it should work 99% of the time. It can (for example) convert the old django repository correctly on the first try, whereas git-svn would give up on the tags.

Hmm, well I'm using it with a repo that has standard
trunks/tags/branches setup with two tags in the tags directory and
when I type hg tags it only lists tip (it shows me all the branches,
however). The hgsbuversion documents say, "Changesets that create tags
cannot be pushed to Subversion, as support for creating Subversion
tags has not yet been implemented," so I thought tag support in
general was missing.  Maybe this svn repo I'm working with has other
issues...

Bryan

From raf at durin42.com  Thu Apr 16 13:38:08 2015
From: raf at durin42.com (Augie Fackler)
Date: Thu, 16 Apr 2015 14:38:08 -0400
Subject: State of Hg-SVN vs Git-SVN
In-Reply-To: <CAPY2A7M48KanmeJ3TRKhK2wpCfb41XaCxtCygSEBWaPfbh_s7Q@mail.gmail.com>
References: <5110525565.20150415192828@TheGallos.com>
	<CAPY2A7N0QK=Y1DAat6KceCMJ3=cA9_LQo3AdO10j3J7aU6oUzA@mail.gmail.com>
	<EDCC7D9E-5214-4084-B488-0CF4753FF738@durin42.com>
	<CAPY2A7M48KanmeJ3TRKhK2wpCfb41XaCxtCygSEBWaPfbh_s7Q@mail.gmail.com>
Message-ID: <175F8B88-0599-4037-B265-2F2D6BF88B2F@durin42.com>


On Apr 16, 2015, at 2:31 PM, Bryan Murdock <bmurdock at gmail.com> wrote:

> On Thu, Apr 16, 2015 at 11:53 AM, Augie Fackler <raf at durin42.com> wrote:
>> 
>> On Apr 16, 2015, at 12:47 AM, Bryan Murdock <bmurdock at gmail.com> wrote:
>> 
>>> Other than the externals caveats, hgsubversion has no support for svn
>>> tags (maybe because they aren't really tags?)
>> 
>> FYI, this is false - hgsubversion has supported tags for at least 6 years. Some complicated setups fool it, but if you actually have a normal trunk/tags/branches setup, it should work 99% of the time. It can (for example) convert the old django repository correctly on the first try, whereas git-svn would give up on the tags.
> 
> Hmm, well I'm using it with a repo that has standard
> trunks/tags/branches setup with two tags in the tags directory and
> when I type hg tags it only lists tip (it shows me all the branches,
> however). The hgsbuversion documents say, "Changesets that create tags
> cannot be pushed to Subversion, as support for creating Subversion
> tags has not yet been implemented," so I thought tag support in
> general was missing.  Maybe this svn repo I'm working with has other
> issues…

hgsubversion can *read* tags from svn just fine. Pushing tags remains unimplemented, because it would be slightly tricky and nobody seems to care enough to do the work.

> 
> Bryan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial/attachments/20150416/0e8f21f2/attachment.pgp>

From err at raelity.com  Thu Apr 16 15:53:03 2015
From: err at raelity.com (Ernie Rael)
Date: Thu, 16 Apr 2015 13:53:03 -0700
Subject: Unexpected- error: pretxncommit.eol hook failed: end-of-line check
	failed:
Message-ID: <5530212F.80305@raelity.com>

Hi all,

Is this expected? I thought the "look for nulls" algorithm was liberally 
applied...

-ernie

$ hg --version
Mercurial Distributed SCM (version 3.3.2)

$ hg ci
error: pretxncommit.eol hook failed: end-of-line check failed:
   .../ScenicView.jar in 00f2468dd899 should not have CRLF line endings

$ od -c 
metaphysical.workbench/ScenicView/release/modules/ext/ScenicView.jar |head
0000000   P   K 003 004  \n  \0  \0  \b  \b  \0 264 205 =   E  \0  \0
0000020  \0  \0 002  \0  \0  \0  \0  \0  \0  \0  \t  \0 \0  \0   M   E
0000040   T   A   -   I   N   F   / 003  \0   P   K 003 004  \n  \0  \0
0000060  \b  \b  \0 264 205   =   E   w   ' 211   r   j \0  \0  \0 235
0000100  \0  \0  \0 024  \0  \0  \0   M   E   T   A   - I   N   F   /
0000120   M   A   N   I   F   E   S   T   .   M   F 215 214 275  \n 203

$ cat .hgeol
[patterns]
** = native

=== from ~/.hgrc
[eol]
native = LF
only-consistent = False

[hooks]
pretxncommit.eol = python:hgext.eol.checkheadshook


From mads at kiilerich.com  Thu Apr 16 16:30:39 2015
From: mads at kiilerich.com (Mads Kiilerich)
Date: Thu, 16 Apr 2015 17:30:39 -0400
Subject: Unexpected- error: pretxncommit.eol hook failed: end-of-line
	check failed:
In-Reply-To: <5530212F.80305@raelity.com>
References: <5530212F.80305@raelity.com>
Message-ID: <553029FF.3030004@kiilerich.com>

On 04/16/2015 04:53 PM, Ernie Rael wrote:
> Hi all,
>
> Is this expected? I thought the "look for nulls" algorithm was 
> liberally applied...

Yes. The eol extension will do what you tell it to do and apply the eol 
check on the patterns you configure. ** means all files - not just all 
"non-binary" files.

The null byte detection is used in places where getting it wrong not 
would be fatal. It would however be quite fatal if eol cleanup was 
applied on a binary file that just happened to not contain any nulls. I 
do thus not think it would be a good idea to have a 'all text files' 
matcher in the eol based on (lack of) null bytes. It could _perhaps_ 
make sense to have something that checked for no control characters at 
all and with something that really looks like all newline delimited lines.

/Mads

>
> -ernie
>
> $ hg --version
> Mercurial Distributed SCM (version 3.3.2)
>
> $ hg ci
> error: pretxncommit.eol hook failed: end-of-line check failed:
>   .../ScenicView.jar in 00f2468dd899 should not have CRLF line endings
>
> $ od -c 
> metaphysical.workbench/ScenicView/release/modules/ext/ScenicView.jar 
> |head
> 0000000   P   K 003 004  \n  \0  \0  \b  \b  \0 264 205 =   E  \0 \0
> 0000020  \0  \0 002  \0  \0  \0  \0  \0  \0  \0  \t  \0 \0  \0 M   E
> 0000040   T   A   -   I   N   F   / 003  \0   P   K 003 004  \n \0  \0
> 0000060  \b  \b  \0 264 205   =   E   w   ' 211   r   j \0  \0  \0 235
> 0000100  \0  \0  \0 024  \0  \0  \0   M   E   T   A   - I   N F   /
> 0000120   M   A   N   I   F   E   S   T   .   M   F 215 214 275 \n 203
>
> $ cat .hgeol
> [patterns]
> ** = native
>
> === from ~/.hgrc
> [eol]
> native = LF
> only-consistent = False
>
> [hooks]
> pretxncommit.eol = python:hgext.eol.checkheadshook
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial


From err at raelity.com  Thu Apr 16 18:35:57 2015
From: err at raelity.com (Ernie Rael)
Date: Thu, 16 Apr 2015 16:35:57 -0700
Subject: Unexpected- error: pretxncommit.eol hook failed: end-of-line
	check failed:
In-Reply-To: <553029FF.3030004@kiilerich.com>
References: <5530212F.80305@raelity.com> <553029FF.3030004@kiilerich.com>
Message-ID: <5530475D.3040303@raelity.com>

On 4/16/2015 2:30 PM, Mads Kiilerich wrote:
> On 04/16/2015 04:53 PM, Ernie Rael wrote:
>> Hi all,
>>
>> Is this expected? I thought the "look for nulls" algorithm was 
>> liberally applied...
>
> Yes. The eol extension will do what you tell it to do and apply the 
> eol check on the patterns you configure. ** means all files - not just 
> all "non-binary" files.

Got it, thanks. Makes sense. I finally put most of the stuff I work with 
into the .hgeol patterns.

I've wondered if having the patterns there saves some performance. 
Thinking about it, I guess the text files still have to be fully 
scanned, I suppose it saves a little since the binary files don't need 
scanning (but usually that null byte shows up quickly I'd guess)

-ernie

>
> The null byte detection is used in places where getting it wrong not 
> would be fatal. It would however be quite fatal if eol cleanup was 
> applied on a binary file that just happened to not contain any nulls. 
> I do thus not think it would be a good idea to have a 'all text files' 
> matcher in the eol based on (lack of) null bytes. It could _perhaps_ 
> make sense to have something that checked for no control characters at 
> all and with something that really looks like all newline delimited 
> lines.
>
> /Mads
>
>>
>> -ernie
>>
>> $ hg --version
>> Mercurial Distributed SCM (version 3.3.2)
>>
>> $ hg ci
>> error: pretxncommit.eol hook failed: end-of-line check failed:
>>   .../ScenicView.jar in 00f2468dd899 should not have CRLF line endings
>>
>> $ od -c 
>> metaphysical.workbench/ScenicView/release/modules/ext/ScenicView.jar 
>> |head
>> 0000000   P   K 003 004  \n  \0  \0  \b  \b  \0 264 205 =   E \0 \0
>> 0000020  \0  \0 002  \0  \0  \0  \0  \0  \0  \0  \t  \0 \0  \0 M   E
>> 0000040   T   A   -   I   N   F   / 003  \0   P   K 003 004  \n \0  \0
>> 0000060  \b  \b  \0 264 205   =   E   w   ' 211   r   j \0  \0 \0 235
>> 0000100  \0  \0  \0 024  \0  \0  \0   M   E   T   A   - I   N F   /
>> 0000120   M   A   N   I   F   E   S   T   .   M   F 215 214 275 \n 203
>>
>> $ cat .hgeol
>> [patterns]
>> ** = native
>>
>> === from ~/.hgrc
>> [eol]
>> native = LF
>> only-consistent = False
>>
>> [hooks]
>> pretxncommit.eol = python:hgext.eol.checkheadshook
>>
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial
>
>
>


From Ross.Boylan at ucsf.edu  Fri Apr 17 21:40:56 2015
From: Ross.Boylan at ucsf.edu (Boylan, Ross)
Date: Sat, 18 Apr 2015 02:40:56 +0000
Subject: sharing across dissimilar installations
Message-ID: <F1F13E14A610474196571953929C02096A69CC@ex08.net.ucsf.edu>

I have some hg repositories created on MS Windows.  They began a few years ago, but I kept my tortoisehg client up to date, which means they been used by quite recent mercurial's, probably 3.2

Hardware failure has caused me to switch to linux with mercurial 2.2, accessing the files by cifs mount.

Is this likely to work?  I have already done a couple of commits.

I have several concerns:
1) The versions of mercurial are incompatible.
2) Spaces in path names.
3) Windows-specific conventions, such as references to drive letters or backward slashes as separators, in control files.

I am not asking about differences in line end conventions in the files under version control; I know they exist and consider them unlikely to cause trouble for me.

The documents I've seen don't suggest there should be much of problem, especially for 1), but it seemed prudent to check.  Some upgrade notes indicate that later versions will have features that may be incompatible with earlier versions, but I haven't got any error messages like that.

From mpm at selenic.com  Sat Apr 18 16:00:30 2015
From: mpm at selenic.com (Matt Mackall)
Date: Sat, 18 Apr 2015 16:00:30 -0500
Subject: sharing across dissimilar installations
In-Reply-To: <F1F13E14A610474196571953929C02096A69CC@ex08.net.ucsf.edu>
References: <F1F13E14A610474196571953929C02096A69CC@ex08.net.ucsf.edu>
Message-ID: <1429390830.31449.13.camel@selenic.com>

On Sat, 2015-04-18 at 02:40 +0000, Boylan, Ross wrote:
> I have some hg repositories created on MS Windows.  They began a few years ago, but I kept my tortoisehg client up to date, which means they been used by quite recent mercurial's, probably 3.2
> 
> Hardware failure has caused me to switch to linux with mercurial 2.2, accessing the files by cifs mount.
> 
> Is this likely to work?  I have already done a couple of commits.
> 
> I have several concerns:
> 1) The versions of mercurial are incompatible.

Every version of Mercurial can read repos _created_ by any older
version.. and will complain otherwise. So if 'hg status' works, you're
golden. I recently discovered that the repo hosting hg itself was
created circa 0.7.. and has obviously worked without trouble since that
time. See here for more details:

http://mercurial.selenic.com/wiki/UpgradingMercurial

> 2) Spaces in path names.

Linux is -way way way- more permissive about filenames.

> 3) Windows-specific conventions, such as references to drive letters
> or backward slashes as separators, in control files.

Except in .hg/hgrc, there shouldn't be any. It's quite common to
move/share repos between Linux and Windows.

> I am not asking about differences in line end conventions in the files
> under version control; I know they exist and consider them unlikely to
> cause trouble for me.

Mercurial internally treats all files as binary; it treats a .txt the
same as a .jpg. Only commands that display diffs or the like make any
attempt to detect if a file is text... so they won't put too much
garbage on your screen.

-- 
Mathematics is the supreme nostalgia of our time.



From raf at durin42.com  Sun Apr 19 11:51:02 2015
From: raf at durin42.com (Augie Fackler)
Date: Sun, 19 Apr 2015 12:51:02 -0400
Subject: sharing across dissimilar installations
In-Reply-To: <F1F13E14A610474196571953929C02096A69CC@ex08.net.ucsf.edu>
References: <F1F13E14A610474196571953929C02096A69CC@ex08.net.ucsf.edu>
Message-ID: <D4766093-178B-49CF-8A3A-FE4B935D4EEE@durin42.com>


On Apr 17, 2015, at 10:40 PM, Boylan, Ross <Ross.Boylan at ucsf.edu> wrote:

> Hardware failure has caused me to switch to linux with mercurial 2.2, accessing the files by cifs mount.
> 
> Is this likely to work?  I have already done a couple of commits.

Only thing to add to mpm’s response is that accessing repositories via CIFS is not a great idea. While it generally seems to work out, I’ve seen cases where CIFS was the most likely cause of surprise corruption.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial/attachments/20150419/afe0b35e/attachment.pgp>

From lists at benjamindsmith.com  Wed Apr 22 19:47:36 2015
From: lists at benjamindsmith.com (Benjamin Smith)
Date: Wed, 22 Apr 2015 17:47:36 -0700
Subject: Git vs Mercurial branches
In-Reply-To: <CAHT=eSof3KPCwmLv7kqOChuFjKNOKRq8ARJdmmECrCHxEb8eRA@mail.gmail.com>
References: <CAHT=eSof3KPCwmLv7kqOChuFjKNOKRq8ARJdmmECrCHxEb8eRA@mail.gmail.com>
Message-ID: <1856426.8k0IZ08thr@tesla.schoolpathways.com>

On Tuesday, March 10, 2015 05:40:13 PM Avner Silberman wrote:
> Rather than focus on the minutiae of how features are implemented and how
> you do something in one system vs the other, I've been looking at reasons
> why one system may be preferable to another from a corporate perspective.
> As a closed source shop what might be key features or missing features that
> would sway the decision?

I love Mercurial! As a tool, it's done me well, and I too like the simplicity 
of it, the ability to set up a repo anywhere, etc. 

Realistically, though, if you've picked your tool and are trying to justify 
its use, you're doing it wrong. 

Identify the *needs* that your organization has, and then work back from 
there. Git and Mercurial are both high-quality, similar products, similar 
enough that you probably aren't going to make a major mistake either way. 
Focus on the needs of your organization and drive the decision from there. 
That way you're most sure to make the best decision. 

From charlie at thegallos.com  Wed Apr 22 20:45:30 2015
From: charlie at thegallos.com (Charles Gallo)
Date: Wed, 22 Apr 2015 21:45:30 -0400
Subject: Git vs Mercurial branches
In-Reply-To: <1856426.8k0IZ08thr@tesla.schoolpathways.com>
References: <CAHT=eSof3KPCwmLv7kqOChuFjKNOKRq8ARJdmmECrCHxEb8eRA@mail.gmail.com>
	<1856426.8k0IZ08thr@tesla.schoolpathways.com>
Message-ID: <EE8EC2FB-EDBA-455F-9832-FA7540BC13F6@thegallos.com>

Yes, that is the plan. Part of the need is to keep the SVN repo around for certain projects, so this question is to help me choose which tool meets our needs better

--  
73 de KG2V
Charlie

> On Apr 22, 2015, at 8:47 PM, Benjamin Smith <lists at benjamindsmith.com> wrote:
> 
>> On Tuesday, March 10, 2015 05:40:13 PM Avner Silberman wrote:
>> Rather than focus on the minutiae of how features are implemented and how
>> you do something in one system vs the other, I've been looking at reasons
>> why one system may be preferable to another from a corporate perspective.
>> As a closed source shop what might be key features or missing features that
>> would sway the decision?
> 
> I love Mercurial! As a tool, it's done me well, and I too like the simplicity 
> of it, the ability to set up a repo anywhere, etc. 
> 
> Realistically, though, if you've picked your tool and are trying to justify 
> its use, you're doing it wrong. 
> 
> Identify the *needs* that your organization has, and then work back from 
> there. Git and Mercurial are both high-quality, similar products, similar 
> enough that you probably aren't going to make a major mistake either way. 
> Focus on the needs of your organization and drive the decision from there. 
> That way you're most sure to make the best decision. 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial

From sean at farley.io  Thu Apr 30 13:44:40 2015
From: sean at farley.io (Sean Farley)
Date: Thu, 30 Apr 2015 11:44:40 -0700
Subject: Mercurial 10th Anniversary
Message-ID: <m2lhh9317r.fsf@farley.io>

Hi everyone,

I wrote a blog post announcing my new job at Bitbucket and also my
experience at the 3.4 sprint:

https://news.ycombinator.com/item?id=9465084

But it's worth mentioning that there is also a meetup that Atlassian is
throwing for Mercurial's 10th Anniversary for people in the Bay Area on
May 6th:

http://www.meetup.com/Bay-Area-Mercurial-Meetup/events/222139518/

I hope to see you all there!

From snidely.too at gmail.com  Thu Apr 30 17:42:40 2015
From: snidely.too at gmail.com (Dave S)
Date: Thu, 30 Apr 2015 15:42:40 -0700
Subject: Mercurial 10th Anniversary
In-Reply-To: <m2lhh9317r.fsf@farley.io>
References: <m2lhh9317r.fsf@farley.io>
Message-ID: <CABex+kjb1QR88=SihEgBAsKmFyThfnM4e4f66q7PGnaXddMmRg@mail.gmail.com>

On Thu, Apr 30, 2015 at 11:44 AM, Sean Farley <sean at farley.io> wrote:

> Hi everyone,
>
> I wrote a blog post announcing my new job at Bitbucket and also my
> experience at the 3.4 sprint:
>
> https://news.ycombinator.com/item?id=9465084
>

Is that the right link?  It seemed to take me to the comments,
but I found a tic mark that got me to
<URL:https://blog.bitbucket.org/2015/04/30/mercurial-onward-and-upward/>


> But it's worth mentioning that there is also a meetup that Atlassian is
> throwing for Mercurial's 10th Anniversary for people in the Bay Area on
> May 6th:
>
> http://www.meetup.com/Bay-Area-Mercurial-Meetup/events/222139518/
>
> I hope to see you all there!
>
>
I'd be real interested in going, but I will probably find myself stuck in
SoCal.

/dps

-- 
test signature -- please apply at front gate on Tuesdays only.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150430/f41438b2/attachment.html>

From sean at farley.io  Thu Apr 30 17:56:36 2015
From: sean at farley.io (Sean Farley)
Date: Thu, 30 Apr 2015 15:56:36 -0700
Subject: Mercurial 10th Anniversary
In-Reply-To: <CABex+kjb1QR88=SihEgBAsKmFyThfnM4e4f66q7PGnaXddMmRg@mail.gmail.com>
References: <m2lhh9317r.fsf@farley.io>
	<CABex+kjb1QR88=SihEgBAsKmFyThfnM4e4f66q7PGnaXddMmRg@mail.gmail.com>
Message-ID: <m2fv7h2pjv.fsf@farley.io>


Dave S <snidely.too at gmail.com> writes:

> On Thu, Apr 30, 2015 at 11:44 AM, Sean Farley <sean at farley.io> wrote:
>
>> Hi everyone,
>>
>> I wrote a blog post announcing my new job at Bitbucket and also my
>> experience at the 3.4 sprint:
>>
>> https://news.ycombinator.com/item?id=9465084
>>
>
> Is that the right link?  It seemed to take me to the comments,
> but I found a tic mark that got me to
> <URL:https://blog.bitbucket.org/2015/04/30/mercurial-onward-and-upward/>

Sorry, yeah, that was a copy & paste error. The right link is what you shared.

>> But it's worth mentioning that there is also a meetup that Atlassian is
>> throwing for Mercurial's 10th Anniversary for people in the Bay Area on
>> May 6th:
>>
>> http://www.meetup.com/Bay-Area-Mercurial-Meetup/events/222139518/
>>
>> I hope to see you all there!
>>
>>
> I'd be real interested in going, but I will probably find myself stuck in
> SoCal.

Aw :-( I hope you can unstuck yourself and make the meetup!