gmane.comp.version-control.mercurial.general

Re: [ANNOUNCE] hgadmin - access and authentication management toolfor multiple mercurial repositories

cowwoc — 2012-05-25T03:53:21

Jakob,

Looks good, except is there any reason you disabled the bug tracker for this
project? The main reason I am considering migrating from hgweb to rhodecode
is the ability for users to change their password remotely (that and being
able to search through file contents of commits).

Remote management is a very big deal. Have you considered tackling that as
part of hgadmin?

Gili


Jakob Krainz-2 wrote


--
View this message in context: http://mercurial.808500.n3.nabble.com/ANNOUNCE-hgadmin-access-and-authentication-management-tool-for-multiple-mercurial-repositories-tp3784759p3987837.html
Sent from the General mailing list archive at Nabble.com.

Re: Bookmarks guide

Jeff Dyke — 2012-05-25T02:03:57

I think this is a great tutorial, but i don't see the true advantage
over a named branch even if that named branch will only live for two
weeks on one persons machine. Perhaps i just need to try to use them
more, but the branches and their intrinsic power/sensibility seems to
outweigh any lightweight benefit I get out of bookmarks.

I'll say that i'm in a shop of 20 and not 100 or 20K, we love named
branches and for individual development they create a branch or clone
and handle their own merge(usually just with clone), which serves two
masters...clean development and allowing more of the eng team
understanding the merge process, which coming from a long line of
version control systems (starting with SCCS), is fantastic.

On Thu, May 24, 2012 at 5:57 PM, Martin Geisler <martin< at >geisler.net> wrote:

Re: Bookmarks guide

Martin Geisler — 2012-05-24T21:57:14


Yeah, you're right -- it's the GTK version maintained by Henrik Stuart:

  https://bitbucket.org/hstuart/hgtk

I should really change it to the Qt version, but I've been slightly lazy
(to switch, I need to figure out where the Qt version stores the window
configuration) and I like GTK better than Qt :)

Re: Aborted commit not actually aborted?

Mads Kiilerich — 2012-05-24T20:50:37

Matt Hurne wrote, On 05/24/2012 09:39 PM:

That is a windows error message. Mercurial did "something" in a place 
where it shouldn't fail, but for some reason it failed and the global 
error handler gave that relatively nice error message instead of 
crashing with a stacktrace.

A stacktrace would however have been useful to figure out exactly where 
the crash happened. From your description it seems like the actual 
commit to the repository succeeded, but it failed before/when writing 
the new 'dirstate' with information of the parent of the working 
directory and which files has been edited.

If you can reproduce it then try to add --traceback.

Abort is not necessarily 'rollback', but all regular operations on the 
storage is append only and can in worst case be recovered safely.

/Mads

Re: Aborted commit not actually aborted?

Matt Mackall — 2012-05-24T20:46:44

Possible. Another possibility is that you have a virus scanner or
similar annoyance.

SV: Bookmarks guide

Roger Kratz — 2012-05-24T19:59:15

Great guide! Thanks a lot.

A question regarding using bookmarks for feature branches I have that's not mentioned in this guide (or that I've found on Google) is how to combine it with a CI build machine. It's probably out of scope of Hg and rather a matter of CI build software but maybe some of you have some experience about it?

Today we use clones for feature branches. When a develop creates a clone we also add a build project for the new clone - all handled in a simple script with no problems. Works fine but it would be nicer with "lighter" bookmark branches I think. The problem is that, AFAIK, isn't really "compatible" with any CI software out there. What I would like is that when a repo is pushed, the heads (bookmarks) are "scanned" and a build was fired specific for the bookmark branch.
Does anyone have any experience with this? Maybe I've missed some CI product out there that supports this out of the box? Or do I have to make this a "hg problem" instead using hooks or similar?

Thanks
Roger

________________________________________
Från: mercurial-bounces< at >selenic.com [mercurial-bounces< at >selenic.com] f&#246;r Martin Geisler [mg< at >aragost.com]
Skickat: den 24 maj 2012 13:54
Till: Mercurial Users
Ämne: Bookmarks guide

Hej guys,

I've written a step-by-step guide to bookmarks:

http://mercurial.aragost.com/kick-start/en/bookmarks/

The idea is to show a full workflow where you create a feature branch,
work on it, share it, merge it, and finally delete the bookmark.

If you read through the guide, you'll find a number of places where
bookmarks don't work very smoothly with Mercurial 2.2. I'm happy that
Mercurial 2.3 will adress some of these problems, in particular by
automatically pulling any bookmarks associated the changesets you pull.

But please try out the guide and let me know what you think. I'll be
using it for some training I do next week, so it would be great if
you'll send comments before that.

The guide is GPLed and you can fork the repository here:

https://bitbucket.org/aragost/kick-start/

--
Martin Geisler

aragost Trifork
Commercial Mercurial support
http://aragost.com/mercurial/
_______________________________________________
Mercurial mailing list
Mercurial< at >selenic.com
http://selenic.com/mailman/listinfo/mercurial

Locally designate a remote server as non-publishing? (For phases)

Michael Forbes — 2012-05-24T19:28:07

How can I locally tell mercurial that a certain remote server is 
non-publishing so that pushing to it will not change all phases to 
'public'?  The docs state that I should modify the hgrc file of the remote 
repo to have publish = false in the [phases] section, but I do not have 
access to that file (the repo is on bitbucket.org, which is still using an 
older version of mercurial anyway.)

It seems to me there should be a simple way of telling my system that a 
particlar repo on a particular server should treated as non-publishing, but 
I cannot figure out how.  If not, I would appreciate any pointers on how to 
implement this as a hook.

Thanks,
Michael.

References:
http://stackoverflow.com/questions/10726360/how-do-i-tell-locally-mercurial-that-a-server-is-non-publishing

Re: Aborted commit not actually aborted?

Matt Hurne — 2012-05-24T20:00:09

I do not have any [hooks] sections in .hg/hgrc in the repository nor
in my user-specific Mercurial.ini.  Is it possible that there is some
hook enabled by default that may have been aborted?  Perhaps one that
is enabled by default in TortoiseHg installations but not in
non-TortoiseHg installations?

Matt Hurne
_______________________________________________
Mercurial mailing list
Mercurial< at >selenic.com
http://selenic.com/mailman/listinfo/mercurial

Re: Aborted commit not actually aborted?

Simon King — 2012-05-24T19:52:47


Do you have any post-commit hooks enabled? It's possible that it's that that was aborted, rather than the commit itself.

Simon

Aborted commit not actually aborted?

Matt Hurne — 2012-05-24T19:39:56

I'm using Mercurial 2.2.1 (installed via TortoiseHg 2.4) on Windows XP
(32-bit).  When committing some changes, I saw the following:

C:\foo>hg commit -m "Lorem ipsum"
abort: The process cannot access the file because it is being used by
another process



It is possible I may have had one or more of the files open at the
time.  I made sure none of the files were open, and ran "hg st", which
showed the list of outstanding changes as I expected.  I then ran the
commit command again:

C:\foo>hg commit -m "Lorem ipsum"
created new head



I didn't expect a new head to be created.  Next, I ran "hg st" and saw
no outstanding changes.  Then I ran "hg heads":

C:\foo>hg heads
changeset:   19:03e9e4fe2d28
tag:         tip
parent:      17:ee1707727153
user:        Matt Hurne <matt< at >thehurnes.com>
date:        Thu May 24 15:11:48 2012 -0400
summary:     Lorem ipsum

changeset:   18:843b16785502
user:        Matt Hurne <matt< at >thehurnes.com>
date:        Thu May 24 15:04:08 2012 -0400
summary:     Lorem ipsum



And here's the output of "hg log -l 3":

C:\foo>hg log -l 3
changeset:   19:03e9e4fe2d28
tag:         tip
parent:      17:ee1707727153
user:        Matt Hurne <matt< at >thehurnes.com>
date:        Thu May 24 15:11:48 2012 -0400
summary:     Lorem ipsum

changeset:   18:843b16785502
user:        Matt Hurne <matt< at >thehurnes.com>
date:        Thu May 24 15:04:08 2012 -0400
summary:     Lorem ipsum

changeset:   17:ee1707727153
user:        Matt Hurne <matt< at >thehurnes.com>
date:        Fri May 18 14:57:15 2012 -0400
summary:     Dolor sit amet



I also took a look with TortoiseHg, and it is clear that changesets 18
and 19 both have 17 as their parent.  I used "hg diff -r 18 -r 19" to
compare the changesets, and there were no differences (no output).  I
ran "hg verify", and it did not report any errors.  Finally, I used
"hg strip" to remove changeset 18:

C:\foo>hg strip -r 18
saved backup bundle to C:\foo\.hg\strip-backup\843b16785502-backup.hg

C:\foo>hg heads
changeset:   18:03e9e4fe2d28
tag:         tip
user:        Matt Hurne <matt< at >thehurnes.com>
date:        Thu May 24 15:11:48 2012 -0400
summary:     Lorem ipsum

C:\foo>hg log -l 3
changeset:   18:03e9e4fe2d28
tag:         tip
user:        Matt Hurne <matt< at >thehurnes.com>
date:        Thu May 24 15:11:48 2012 -0400
summary:     Lorem ipsum

changeset:   17:ee1707727153
user:        Matt Hurne <matt< at >thehurnes.com>
date:        Fri May 18 14:57:15 2012 -0400
summary:     Dolor sit amet

changeset:   16:f4226c5c198d
user:        Matt Hurne <matt< at >thehurnes.com>
date:        Thu May 17 10:05:16 2012 -0400
summary:     Consectetur adipisicing elit



My repository is now in a state I'm happy with, so I don't need help
"fixing" it.  But I thought it was strange that even though the commit
was supposedly aborted, a changeset still existed in the repository
for that commit.  Is this behavior expected/normal?

Thanks,
Matt Hurne

Re: Bookmarks guide

Scott Palmer — 2012-05-24T18:23:54


This is an excellent guide.  My only comment so far is that the version of TortoiseHG that you are using for your screenshots does not appear to be the default TortoisHG UI.  (I think I recall from some other post that you preferred a different version)
That took a little getting used to for me, but it wasn't that big of a deal.

Thanks for this.

Scott

Use hg commit --amend to change the files that are included in acommit

Angel Ezquerra — 2012-05-24T18:20:07

Hi,

I added support for the "hg commit --amend" command to the most recent
release of TortoiseHg. I just found out that using TortoiseHg it is
not possible to "Amend" a revision to change the files that are
included in that revision. I assume that this should be possible
(although the hg help commit is a little vague on this point). Thus I
guess that the command that TortoiseHg is executing is wrong.

As an example, lets say that the tip of a repository is in the draft
phase and that it contains 2 files: "a.txt" and "b.txt". If I select
the "Amend" option in the TortoiseHg commit widget, deselect on of the
files (e.g. "b.txt") and I click "Amend" the amend will not remove
"b.txt" from the tip revision.

The command that TortoiseHg executes is:

hg commit --repository C:\example_repo --verbose --user Angel Ezquerra
<angel.ezquerra< at >gmail.com> --message=this amend will not work as
expected --amend -- C:\example_repo/a.txt

Is this command wrong?

Thanks,

Angel

Re: Bookmarks guide

Sean Farley — 2012-05-24T15:01:34

This is really cool! Thanks Martin!

Re: commit message encoding in windows and hgweb on apache

Wujek Srujek — 2012-05-24T15:12:13

Hi. Fixed - there was some apache directive that set us-ascii as default
encoding, and that was the problem. It works now.

Thanks.

On Thu, May 24, 2012 at 4:42 PM, Wujek Srujek
<wujek.srujek< at >googlemail.com>wrote:

Re: commit message encoding in windows and hgweb on apache

Wujek Srujek — 2012-05-24T14:42:19

I have a hgweb.fcgi file that look like this:

#!/usr/bin/env python

import os

config = "/usr/local/hgweb/hgweb.conf"
os.environ["HGRCPATH"] = config


import cgitb; cgitb.enable()
from mercurial import demandimport; demandimport.enable()
from mercurial.hgweb import hgweb

from flup.server.fcgi import WSGIServer
application = hgweb(config)
WSGIServer(application).run()


and a hgweb.conf (addressed in the fcgi above):

[extensions]
highlight =

[paths]
/ = /repositories/mercurial/*

[web]
allow_archive = gz zip bz2
baseurl = hg
push_ssl = False

And yes, I the settings (like the highlight extension, or allowed archives)
do work.

I tried putting os['HGENCODING'] = 'UTF-8' in the fcgi script, and setting
web.encoding = UTF-8 in the conf file, none of them worked.

I don't think it is a mercurial bug, I think there is something fishy about
our apache2 config - in another company I had both apache2 and lighttpd
used in the same way, and it all just worked. The original apache2
administrator here is on holiday, maybe he will know what's wrong. Until he
comes back, I am really clueless...

wujek

On Thu, May 24, 2012 at 4:21 PM, Benoît Allard <benoit< at >aeteurope.nl> wrote:

RE: commit message encoding in windows and hgweb on apache

Benoît Allard — 2012-05-24T14:21:10

Oh, I hadn't seen this, sorry.

Somehow, it still looks like as if the apache application really likes 'us-ascii'.

May I ask in which configuration file you added the web.encoding = UTF-8 ? If you put something else in this same configuration file (like web.allow_archive=zip), do you see it propagated (i.e. do you see the download link)? What I'trying to figure out is if the web application reads and use this config file. As apache often runs under a specific user with a restrained environment, it's not always clear which config files he uses.

If all of those produce the expected output, but your encoding remains enchanged, I think you found a bug in the encoding detection. Only weird that it works fine over there, and on a lot of other places in the web ...

Regards,
Benoît.

Re: Tracking repository version numbers between releases

Simon King — 2012-05-24T13:37:43

The simplest solution might be to store the next version number inside
the repository (eg. VERSION.txt at the root of the repository). Your
release process would then become:

hg tag release-1.1
echo 1.2 >VERSION.txt
hg ci VERSION.txt -m "Bump version number for next release"

Simon

Re: Tracking repository version numbers between releases

Isaac Jurado — 2012-05-24T13:36:15

Funny, we use that to maintain a deploy log, in case there is an
emergency and need to deploy backwards to a previously known revision:

now=$(date '%F %H:%M:%S')
hg log --rev . --template "$now - {node}
({latesttag}+{latesttagdistance}) [{branch}]\n" >>deploy_history.log

Results in something like this:

2012-05-11 19:23:29 - b7a4ee425c127cac308e0d7cfcc3067204e33e18 (1.9+9) [stable]
2012-05-12 02:51:21 - 0bbd042193b98530ee0e8d93d0f3e935446cc59f (1.9+13) [stable]

Pretty useful.

Re: Tracking repository version numbers between releases

Mads — 2012-05-24T13:23:48

...

A slightly secret way to do that is to use something like
   $ hg parents --template '{latesttag}+{latesttagdistance}-{node|short}'
   2.2.1+119-d0b9ebba41e9

If you use named branches it might be better to use
   $ hg parents --template 
'{branch}-{latesttag}+{latesttagdistance}-{node|short}'
   default-2.2.1+119-d0b9ebba41e9

You might want to omit the distance (and perhaps the hash and probably 
the branch name) if you are building directly on a tag (where the 
distance is 0).

/Mads

Tracking repository version numbers between releases

Tom Anderson — 2012-05-24T12:52:26

Hello everyone,

I spend a lot of time thinking about build and release. Recently, i've 
been thinking about versioning of built artefacts.

I'm fairly sure i'd like a workflow that looks like:

$ hg tag -r <something> release-1.1
$ hg up release-1.1
$ BUILD-MY-PROGRAM
$ build/myprogram --version
1.1

So, we define releases of specific versions by tags, and then build from 
those tags, with the version number embodied in the tag being baked into 
the artefact.

This is pretty easy. The tagging is trivial, and the build can look for 
a release tag by saying hg id -t.

Where this gets a bit trickier is with the builds in between releases. 
Development builds, in particular ones produced by a build server and 
possibly distributed to consumers such as QA.

If i make a release 1.1, and then later on 1.2, then really, the 
versions in between should be something like 1.2-SNAPSHOT-789. That is, 
they should be snapshot versions of the following release. This is 
compatible with both the Maven versioning standard 
(http://docs.codehaus.org/display/MAVEN/Versioning) and semantic 
versioning (http://semver.org/).

Obviously, it is not possible to construct such versions from release 
versions before the release versions have been defined. If i do:

$ hg up tip
$ hg tag release-1.1

Then is the next release version 1.2, 1.1.1, or 2.0?

Instead, we will need to somehow capture the idea of the next due 
release version, and update that at the same time as tagging a release. So:

$ hg up tip
$ hg tag release-1.1
$ SOMEHOW-SET-NEXT-VERSION 1.2
$ # hack hack hack
$ hg commit -m 'hack hack hack'
$ BUILD-MY-PROGRAM
$ build/myprogram --version
1.2-SNAPSHOT-whatever

That next version number needs to move around with changesets, so when 
we cut a release from the build server, we can push something back to 
the main repository, and developers will pick up the fact that they're 
now working towards a new version.

Can anyone suggest a good way of doing this?

Four things spring to mind.

Zero is to use a named branch. The SOMEHOW-SET-NEXT-VERSION 1.2 
operation would be:

$ hg branch 1.2

The problem with that is that it means not developing on default. That 
would be a pain. Also, it means you can't use named branches for 
anything else.

One is to use bookmarks. We could say:

$ hg bookmark -d dev-1.1
$ hg bookmark dev-1.2

However, because only one bookmark can be active at a time (right?) any 
other use of bookmarks in development would disturb the maintenance of 
this information.

Two is to use a special tag. We could say:

$ hg tag dev-1.2

And the fact that that is the most recent dev-* tag in your history 
would tell you you were working towards 1.2. Is there any way to ask for 
things like 'most recent tag'? How about 'most recent tag matching this 
pattern'?

Three is to put some secret sauce in the release tag commit message. Like:

$ hg tag release-1.1 -m "Added tag release-1.1 for changeset $(hg id 
-i); next tag will be release-1.2"

I have no idea how you'd use this information. Nor how you'd handle 
divergent branches - after tagging 1.1, i might well want to have two 
branches (which might not be named branches), one for 1.2, and one for 
1.1.1. This approach only allows for a single next release. I suppose 
that on the 1.1.1 branch, you'd just make a second commit of the same 
tag, with a different message. Blech.

Any thoughts welcome!

Thanks,
tom

Re: commit message encoding in windows and hgweb on apache

Wujek Srujek — 2012-05-24T11:59:53

Hi. In the first message I wrote that I already tried that. First of all,
the machine is a Debian with UTF-8; I still tried the HGENCODING trick but
it didn't work. The thing is, when I 'hg serve' the repository, it is all
good, so the server machine encoding is correct. Only when I use the repo
browser behing apache2 does it result in us-ascii, that's why I suspect
there is something wrong with our setup.

wujek

On Thu, May 24, 2012 at 12:53 PM, Benoît Allard <benoit< at >aeteurope.nl> wrote: