gmane.comp.version-control.mercurial.general

THG -- tab hover-tip for repo path?

Dave S — 2012-05-25T23:07:51

(I know, not a general Hg question.  Sorry)

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

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

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

Thanks.

/dps

SVN-Mercurial conversion problems

Marko Asplund — 2012-05-25T16:04:38

Hi,

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

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

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

and another repository conversion fails with this error:

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

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

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

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


thanks,
marko

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

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

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

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

Bookmarks guide

Martin Geisler — 2012-05-24T11:54:44

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/

commit message encoding in windows and hgweb on apache

Wujek Srujek — 2012-05-23T07:29:12

Hi. We have a windows machine with mercurial 2.2.1, and hg debuginstall
showed that encoding is cp1252 (it's a german installation). A commit was
made, and the commit message included some german characters (namely ü);
the commit was made in Eclipse with workspace encoding set to UTF-8, if it
is important. Then, hg tip on the command line showed a ? instead of ü.
Moreover, when I go to hgweb, it also shows the ?, for any encoding I tried
(most notably, utf-8, cp1252, iso-8859-1). (As a side question, the page
source generated by hgweb doesn't include any encoding metainformation, is
that right?). I think the web site is actually shown in ASCII, replacing
any unknown characters with ?.

What is strange is, when I go to the server and invoke hg tip, the output
is correct. Also when I clone the repository on my machine the output is
correct. When I serve the local clone, or when I look at it with the hgview
tool, it is also correct. Both my machine and the server are using Linux,
and have LANG=en_US.UTF-8 set. When I change encodings of the locally
served repo sites in my browser, the characters get mangled, it is showed
correctly only in UTF-8 - this would suggest that the metadata does come as
UTF-8, es expected and described here:
http://mercurial.selenic.com/wiki/EncodingStrategy.

However, why doesn't the text get changed when I play with the encodings of
the server machine (which is also a Linux box, as mentioned before)? When I
go to the repositories on the remote machine, invoke hg serve inside, and
navigate to the sites generated by the internal web server, the text is
shown correctly, and it's UTF-8.
The 'normal' hgweb is configured to use apache2. This would mean that there
is something broken with the apache setup, but also the windows cli cannot
show it correctly.

I tried this, as mentioned here:
http://mercurial.selenic.com/wiki/PublishingRepositories#Indicating_the_encoding_of_served_content

os.environ["HGENCODING"] = "UTF-8"

and

[web]
encoding = UTF-8
in the hgweb.conf file

but to no avail.

Could anybody give me some more clues as to what needs to be done here?

Regards,
wujek

Rebasing a draft (or secret) revision on top of a public revisionturns the rebased revision public

Angel Ezquerra — 2012-05-23T06:29:26

Hi,

I just found out that if you rebase a draft or a secret revision on
top of a public revision, the rebased revision becomes public. This
has the side effect that if there are rebase conflicts and you try to
abort the rebase, the rebase cannot be aborted.

Is this the correct behavior? It does not seem so to me.

Cheers,

Angel

Merge Tool/Process to Auto-Resolve Conflicts

Jensen, Aaron — 2012-05-22T17:42:35

We have a repository full of well-structured application reference data: 500 files, 1 GB of disk space in the working directory, 400MB of space in the repository (.hg directory).  There are two branches: stable and default.  We have a nightly automated processes to export the latest data.  In order to decrease the growth of the repository, the export process looks like this:


1.       Export from stable

2.       Merge stable into default

3.       Export default

I merge so that data similarities between the two branches aren't made across multiple changesets.  (I'm assuming this helps keep the repository smaller.)
Sometimes there are conflicts when merging between the two branches.  Because of the nature of our data, the rules for resolving merge conflicts are known. Non-conflicting changes should flow from stable into default.  When there are conflicts, the resolution is to ALWAYS take/prefer/use the changes from local/default.

Is there a way to tell Mercurial to merge normally, but for conflicts take one side or the other?  Is there a merge tool that will do that?  Or am I going to have to write my own custom merge tool?

     <:> Aaron

web view of the changes in file - no diff, but two columns with oldand new contents

Wujek Srujek — 2012-05-22T14:59:31

HI. Is there a way to configure hgweb so that when a file in a changeset is
clicked, the changes are not shown as a diff, but rather as two columns
with the old and the new contents, maybe even with green / red lines for
added / removed? If not, is there any tool you know that would provide this
functionality?

wujek

merge 2 non-head revisions

Mihamina Rakotomandimby — 2012-05-21T14:52:33

Hi all,

I was convinced I could merge any revisions I want, and yesterday I 
tried (with TortoiseHG/Windows), but I got 2 red error messages saying 
the 2 revisions I wanted to merge are not heads.

To proceed, I "update --clean" to a non-head revision, pick anoter 
non-head revision and ask for the merge (right-click and merge).

This is usefull for me because some collegues committed a first merge 
with their 2 heads (so, no error message about merging non-heads), but 
the merge+commit was not as good as that. So I have to commit another 
merge taking the same revision they took  which are not head anymore 
because they have the "bad" merge as child.

All is in the "default" branch.

What to do to correctly merge in that case (staying on "default" branch)?
- One solution I found is to commit anything from the 2 revisions to 
make heads and then make the merge. I find that a bit dirty...
- Another solution is to use named 2 branches from the 2 revisions, 
seems to be overkill...
- What else?...

Thank you.

Question about repository structure

Ken Halprin — 2012-05-20T20:57:45

I'm moving from SourceSafe to Mercurial (finally), and want to get a little
feedback on repository structure. Here's a description of what we have now
and my thoughts on how to move forward.

 

Description of code

Our product is built with a client/server architecture. The client
application is fairly small with little sharing of components. The server
application is big with a plug-in type architecture. This is where most of
my questions arise. The plug-ins use shared source code files to implement
the interface between the main application and the plug-ins. There are about
three types of plug-ins, all of which share at least some source code files.
However, within the various types of plug-ins there is also some number of
shared files that are used by some but not all plug-ins. This works fine in
SourceSafe since it shares at the file level.

 

In SourceSafe, the structure looks something like this:

 

PlugIn1

                SharedFile1

                SharedFile2

                Plugin1File1

                Plugin1File2

 

Plugin2

                SharedFile1 (link)

                SharedFile2 (link)

                SharedFile3 (link)

                Plugin2File1

                Plugin2File2

 

Plugin3

                SharedFile1 (link)

                SharedFile3 (link)

                Plugin3File1

 

 

I've thought about the conversion in different ways over time, from using
multiple individual repositories, to a repository with many
sub-repositories. I believe I've settled upon the idea of creating one
repository for the entire server application. The files that are shared
would be moved to a sub-directory within the repository so they exist in
only one location, and the individual plug-in projects that use them would
just reference the files in their new location instead of in each projects'
directory (as exists now with SourceSafe).

 

Proposed Mercurial structure:

 

Server

SharedFiles

                                SharedFile1

                                SharedFile2

                                SharedFile3

                                SharedFile1

                                SharedFile3

 

PlugIn1

                                ..\SharedFiles\SharedFile1

                                ..\ SharedFiles\SharedFile2

                                Plugin1File1

                                Plugin1File2

 

Plugin2

                                ..\SharedFiles\SharedFile1

                                ..\ SharedFiles\SharedFile2

                                ..\ SharedFiles\SharedFile3

                                Plugin2File1

                                Plugin2File2

 

Plugin3

                                ..\SharedFiles\SharedFile1

                                ..\ SharedFiles\SharedFile3

                                Plugin3File1

 

 

Does anyone have any comments about this structure, or potential gotchas
that might arise?

 

Ken Halprin

Fwd: Aw: Re: Mercurial in a corporate environment (Re: Atlassianintroduced Stash without Mercurial support)

Paul Boddie — 2012-05-18T17:02:29

Forwarded to the list with permission...

-------- Original Message --------
Subject: Aw: Re: Mercurial in a corporate environment (Re: Atlassian
introduced Stash without Mercurial support)
Date: Wed, 16 May 2012 14:46:43 +0200 (CEST)
From: Arne Bab. <arne_bab< at >web.de>
To: Paul Boddie <paul.boddie< at >biotek.uio.no>

  > Wasn't there at least one peer-to-peer extension for Mercurial? For
  > example, one could do sharing over things like XMPP with a suitable
  > extension.

There is infocalypse, which allows serving Mercurial repositories over
Freenet: Anonymized, decentralized, encrypted and only accessible to
those who know the request key:
http://mercurial.selenic.com/wiki/Infocalypse

*Gesendet:* Dienstag, 15. Mai 2012 um 15:48 Uhr
*Von:* "Paul Boddie" <paul.boddie< at >biotek.uio.no>
*An:* "Tom Anderson" <tom.anderson< at >timgroup.com>
*Cc:* mercurial< at >selenic.com
*Betreff:* Re: Mercurial in a corporate environment (Re: Atlassian
introduced Stash without Mercurial support)
On 15/05/12 15:09, Tom Anderson wrote:
  > On 11/05/12 02:04, Stephen Morton wrote:
  >

[On hgweb shortcomings]

  >
  > The Mercurial equivalent of the Spitfire would be a bundle containing
  > Mercurial, a lightweight webserver, or an SSH daemon, and the necessary
  > configuration to wire the bits together, plus such plugins and global
  > configuration as are necessary to supply all the features a complete SCM
  > solution needs. On systems with package managers (which is what you'd
  > probably be using to host this), this could be a small package which
  > pulls all the other bits in as dependencies, and then supplies some
  > configuration files and a command which starts everything in the
right way.

Package management gets you most of the way, but the configuration is
always a tricky thing to get right. It's possible that the package
defaults are what you want, but in practice
RHEL/EPEL/Fedora/Debian/Ubuntu packages target a really basic
configuration that most people will want to override: a Web application
at some "good enough" URL that you'd change to make sense to your users,
a database cluster with a "good enough" encoding and configuration that
you'd change to work for your own databases, and so on. The hard part is
then to make that configuration easy for people.

There are also situations where the available packages aren't what
people want to use, too, but I'd recommend that most people install as
much as possible from packages: there might be a need for more variation
or flexibility in the packages acting as icing/frosting (Mercurial in
this case), but the recipe for the cake (Python, various system
libraries) should remain as close to that recommended (and delivered as
packages) as possible.

For moinsetup (setting up MoinMoin), I have tried to have the
configuration activity controlled by just a few master settings, even
going as far as to make it compatible with distribution practices (and
not require a special installation of the software), although there's
surely more to be done. The goal is to eliminate all the little steps
that people don't regard as being worth automating, because ultimately
those little steps in the instructions, if omitted, lead to all sorts of
weird errors and tedious troubleshooting. Consider permissions issues as
the most well-known example of that.

[...]

  >> * Hg serve has no security at all. So how do designers actually use
  >> the DCVS in a distributed way?
  >
  > Email a patch? Or, when you want someone to pull something:
  >
  > hg serve --prefix $(dd if=/dev/urandom bs=32 count=1 2>/dev/null |
  > base64 | tr / -)
  >
  > Then tell them the URL, then kill the serve once they've pulled.
  > Platforms without dd, base64, or sed can substitute some random
  > key-mashing for the parenthesised expression.

Wasn't there at least one peer-to-peer extension for Mercurial? For
example, one could do sharing over things like XMPP with a suitable
extension.

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

Ihr WEB.DE Postfach immer dabei: die kostenlose WEB.DE Mail App für
iPhone und Android.
*https://produkte.web.de/freemail_mobile_startseite/*

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

uisetup in record extension looks up mq - but the official docs sayit shouldn't

Wujek Srujek — 2012-05-17T13:58:58

Hi. The record.py file has the following (in tip):

def uisetup(ui):
    try:
        mq = extensions.find('mq')
    except KeyError:
        return

but the doc found here:

http://mercurial.selenic.com/wiki/WritingExtensions#extsetup

explicitly say that extsetup is the right place. This would mean that
uisetup might fail, i.e., not find mq, right?

On the other hand, record works just fine, which would imply that either
the cited page doesn't tell the whole truth, or the exts are loaded in
alphabetical order? How does this really work?

wujek

'help' in default pager.attend list?

Wujek Srujek — 2012-05-17T09:36:07

Hi. I have spent some time recently reading mercurial help, and I
personally thing it would be handy if the default pager.attend list
included the help command as well. There are command that are short and
simple, but there are also commands that require some more explanation,
especially with the -v flag turned on. With 'less -FRSX' as the pager, the
short commands are simply cat-ed to the screen. I know I can set
pager.attend to an empty list, but this requires some more configuration,
and actually is nowhere to be found except for the docstring of the
extension (or the wiki page says it in a convoluted way, I am not sure ;d).
What do you think?

wujek

Subrepos pull/update failure (abort: default path for subrepositorynot found)

Eric Wing — 2012-05-16T22:21:09

I just went through some workflow problems with subrepos that I
thought I would share to help anybody else that might run into the
same problem or possibly start a discussion on how this might be
better handled in Mercurial.


I am starting to add subrepos to an existing project where a lot of us
already have clones lying around. We are using relative paths in our
.hgsub, e.g.

external/luafilesystem = external/luafilesystem
external/OpenFeint = external/luafilesystem

This is to facilitate making both local clones and clones from our
main server. We made sure our main server is laid out so it is
compatible with by defining things in the [subpaths] section of
.hgsub.


The problem I have been encountering is when I do an 'hg pull <repo>;
hg update' (or hg merge) with an already existing clone that does not
yet have the newly added subrepos. When I do the update, I may get a
failure like:
abort: default path for subrepository external/luafilesystem not found

I noticed that the subrepo directory is created when I do the update,
but it is an empty husk of a repo as if you had just run 'hg init'.

Fresh clones do not have this problem. Only existing repositories that
need the new subrepository will get this problem.

I can fix/workaround the problem by directly cloning the subrepo to
the correct location in my repo. Then 'hg update' will start working
again for subsequent operations.


After fighting this problem for myself and my coworkers that were
encountering the issue, I think I now have a basic understanding of
the problem. I determined that doing 'hg pull -u <repo>" also avoids
the problem. So what I think is going on is that doing an 'hg update'
when a subrepo needs to be created fails because it needs to do a
clone of the subrepo. But 'hg update' doesn't have any repo path
information of where to get the clone because that information was
tied to the pull, not the update. Initial/fresh clones avoid this
problem since they clone the subrepos immediately.

I also discovered that if you have a default path in your .hgrc, hg
update will try to use that.

But in my case, I had actually removed the default path in my .hgrc
[paths] because I don't want to accidentally push to it. So I wasn't
getting this behavior. In my coworkers's cases, their default paths
were set to something that only works on our local network and they
happened to be outside our network using a tunnel so the default
location would not work.


So I thought I share these findings to save anybody some possible headaches.


As how Mercurial might better handle this, I'm not really sure. Though
maybe a more descriptive error message explaining why the subrepo
failed would be helpful.

But one idea is that .hgsub could have a new field like
[fallback_subpath] so when nothing resolves normally, this is invoked.
Arguably, this should actually be hit before you hit the default path
in your .hgrc.


Thanks,
Eric

Bug/regression: default clone destination no longer working

Jakob Hunsballe — 2012-05-16T16:11:17

The following used to work - by cloning into a new directory named "repos"

$ hg clone ssh://user< at >server/repos

but now fails:

$ hg clone ssh://user< at >server/repos
** unknown exception encountered, please report by visiting
**  http://mercurial.selenic.com/wiki/BugTracker
** Python 2.6.1 (r261:67515, Aug  2 2010, 20:10:18) [GCC 4.2.1 (Apple Inc. build 5646)]
** Mercurial Distributed SCM (version 2.2.1+100-99f369f5a8db)
** Extensions loaded: big-push, nobranch, caseguard, extdiff, progress, purge, rebase, transplant, largefiles, mq, color, record, mercurial_keyring
Traceback (most recent call last):
  File "/usr/bin/hg", line 38, in <module>
    mercurial.dispatch.run()
  File "usr/local/lib/python2.6/site-packages/mercurial/dispatch.py", line 28, in run
  File "usr/local/lib/python2.6/site-packages/mercurial/dispatch.py", line 65, in dispatch
  File "usr/local/lib/python2.6/site-packages/mercurial/dispatch.py", line 88, in _runcatch
  File "usr/local/lib/python2.6/site-packages/mercurial/dispatch.py", line 699, in _dispatch
  File "usr/local/lib/python2.6/site-packages/mercurial/dispatch.py", line 473, in runcommand
  File "usr/local/lib/python2.6/site-packages/mercurial/extensions.py", line 184, in wrap
  File "usr/local/lib/python2.6/site-packages/hgext/color.py", line 362, in colorcmd
  File "usr/local/lib/python2.6/site-packages/mercurial/dispatch.py", line 789, in _runcommand
  File "usr/local/lib/python2.6/site-packages/mercurial/dispatch.py", line 760, in checkargs
  File "usr/local/lib/python2.6/site-packages/mercurial/dispatch.py", line 696, in <lambda>
  File "usr/local/lib/python2.6/site-packages/mercurial/util.py", line 463, in check
  File "usr/local/lib/python2.6/site-packages/mercurial/extensions.py", line 139, in wrap
  File "usr/local/lib/python2.6/site-packages/mercurial/util.py", line 463, in check
  File "usr/local/lib/python2.6/site-packages/hgext/largefiles/overrides.py", line 708, in overrideclone
NameError: global name 'defaultdest' is not defined


Cheers..
/Jakob

mercurial.ini file read by apache+hgweb

Angel Ezquerra — 2012-05-16T15:29:38

Hi,

I have a mercurial server that runs under WSGI on Apache on a
WindowsXP machine. The server runs as the SYSTEM user. The only
mercurial version installed on the server is the mercurial "source"
packages, that is installed in
c:\Python26\libs\site-packages\mercurial (and the corresponding
extensions which are found in c:\Python26\libs\site-packages\hgext).
There is no mercurial executable installed.

I'd like to enable the largefiles extension on the server. At first I
thought that I could do it on the hgweb.config file that is used by
the server. However this does not seem to work.

So, where can I find the server's mercurial settings file?

The hgrc page on the wiki
(http://www.selenic.com/mercurial/hgrc.5.html) says that the user
config files on windows are:

%USERPROFILE%\.hgrc
%USERPROFILE%\Mercurial.ini
%HOME%\.hgrc
%HOME%\Mercurial.ini

It also says that the system configuration files are:

<install-dir>\Mercurial.ini or
<install-dir>\hgrc.d\*.rc or
HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial

None of these seem to be relevant, since AFAIK there really is no
SYSTEM user profile folder and there is no mercurial installation
folder, unless you count the site-packages folder.

Thanks,

Angel

hg help -v diff bug?

Wujek Srujek — 2012-05-16T12:56:04

The help says at some point, in the examples area:

- compare two historical versions of a directory, with rename info:

        hg diff --git -r 1.0:1.2 lib/

The -r 1.0:1.2 parts seems strange, and I cannot make it work. What does it
mean? Or is it typos?

wujek

hg convert -d svn not working (ever), syncing hg with svn

Wujek Srujek — 2012-05-16T06:33:26

Hi. I am invoking this command:
hg convert -d svn test-hg file:///home/tester/Playground/svnrepo/test
--traceback
initializing svn working copy 'test-wc'
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 87,
in _runcatch
    return _dispatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 685,
in _dispatch
    cmdpats, cmdoptions)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 467,
in runcommand
    ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line
184, in wrap
    return wrapper(origfn, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/hgext/pager.py", line 107, in
pagecmd
    return orig(ui, options, cmd, cmdfunc)
  File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line
184, in wrap
    return wrapper(origfn, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 362, in
colorcmd
    return orig(ui_, opts, cmd, cmdfunc)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 775,
in _runcommand
    return checkargs()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 746,
in checkargs
    return cmdfunc()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 682,
in <lambda>
    d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 463, in
check
    return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/hgext/convert/__init__.py", line
269, in convert
    return convcmd.convert(ui, src, dest, revmapfile, **opts)
  File "/usr/lib/python2.7/dist-packages/hgext/convert/convcmd.py", line
439, in convert
    destc = convertsink(ui, dest, opts.get('dest_type'))
  File "/usr/lib/python2.7/dist-packages/hgext/convert/convcmd.py", line
70, in convertsink
    return sink(ui, path)
  File "/usr/lib/python2.7/dist-packages/hgext/convert/subversion.py", line
1042, in __init__
    self.run0('checkout', path, wcpath)
  File "/usr/lib/python2.7/dist-packages/hgext/convert/common.py", line
323, in run0
    self.checkexit(status, output)
  File "/usr/lib/python2.7/dist-packages/hgext/convert/common.py", line
319, in checkexit
    raise util.Abort('%s %s' % (self.command, msg))
Abort: svn exited with status 256
abort: svn exited with status 256

As you see, it doesn't work. I tried googling around, and found a few
people saying that I should ignore 256 and just continue. However, they
said this happens every now and then, like here:
http://stackoverflow.com/questions/1898994/converting-from-mercurial-to-subversion,
where it is said it happens after 2 revisions and was a filesystem problem.
For me, it happens always.

I can convert from svn to mercurial no problem here, hg version 2.2.1,
python-subversion 1.6.17 (from ubuntu package), subversion 1.6.17 (also
from ubuntu packages), filesystem type: ext4.

As an aside question: what limitation does converting from hg to svn have?
The help says branch history is not preserved, but is it only for merged
branches, or branching altogether (like having many anonymous branches?).
How does it convert merges?

The origin is the following: after a presentation I have, some of the devs
here decided to give mercurial a try, so I'm converting a few projects that
have some traffic, and we will use hg for a few days / weeks. If the tools
(eclipse plugin, idea plugin, tortoise) work, we will forget svn. Up to
that point, they want to synchronize the hg commits to subversion. What is
the canonical way of doing this, apart from convert, which doesn't work
here? I also tried writing a hook that act on incoming in the central hg
repo, and syncs with svn via a 'sync working copy', but this of course
doesn't work as soon as there are merged anonymous branches. What did you
use? Is it at all feasible?

wujek