http://blog.gmane.org/gmane.comp.version-control.mercurial.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.version-control.mercurial.general/31066 <pre>Hi. I implemented a first draft of the column (side-by-side) diff and would like to share my initial result for any pointers and review, and also ask a few questions. First and foremost, the idea how to implement it is pretty much the same as the idea behind the corresponding functionality (called fulldiff) in SonicHG, so I would like to thank the author for his code. I just extracted this functionality from his code and refactored it a bit. The patch is at the end of this email. It is not complete yet (no templates supported, no test yet, ...), but I would like to ask a few question about whether it is the right direction. It applies on the latest commit on stable in the repository maintained by Matt, as I can't make hgweb work on default (I get a 'mqrepo has no attribute branchtip' or similar, and when I disable mq, there is some other problem with localrepo, maybe even the same attribute). I also attach a screenshot that shows what it looks like (google chrome on ubuntu 12.04, so I am not sure about the</pre> Wujek Srujek 2012-05-26T09:50:44 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/31062 <pre>(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 </pre> Dave S 2012-05-25T23:07:51 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/31051 <pre>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 </pre> Marko Asplund 2012-05-25T16:04:38 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/31020 <pre>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</pre> Michael Forbes 2012-05-24T19:28:07 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/31017 <pre>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&gt;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&gt;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&gt;hg heads changeset: 19:03e9e4fe2d28 tag: tip parent: 17:ee1707727153 user: Matt Hurne &lt;matt&lt; at &gt;thehurnes.com&gt; date: Thu May 24 15:11:48 2012 -0400 summary: Lorem ipsum changeset: 18:843b16785502 user: Matt Hurne &lt;matt&lt; at &gt;thehurnes.com&gt; date: Thu May 24 15:04:08 2012 -0400 summary: Lorem ipsum And here'</pre> Matt Hurne 2012-05-24T19:39:56 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/31015 <pre>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 &lt;angel.ezquerra&lt; at &gt;gmail.com&gt; --message=this amend will not work as expected --amend -- C:\example_repo/a.txt Is this command wrong? Thanks, Angel </pre> Angel Ezquerra 2012-05-24T18:20:07 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/31007 <pre>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 &lt;something&gt; 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 </pre> Tom Anderson 2012-05-24T12:52:26 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/31005 <pre>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/ </pre> Martin Geisler 2012-05-24T11:54:44 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30996 <pre>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</pre> Wujek Srujek 2012-05-23T07:29:12 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30994 <pre>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 </pre> Angel Ezquerra 2012-05-23T06:29:26 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30987 <pre>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 o</pre> Jensen, Aaron 2012-05-22T17:42:35 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30986 <pre>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 </pre> Wujek Srujek 2012-05-22T14:59:31 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30983 <pre>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.</pre> Mihamina Rakotomandimby 2012-05-21T14:52:33 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30980 <pre>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 </pre> Ken Halprin 2012-05-20T20:57:45 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30975 <pre>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. &lt;arne_bab&lt; at &gt;web.de&gt; To: Paul Boddie &lt;paul.boddie&lt; at &gt;biotek.uio.no&gt; &gt; Wasn't there at least one peer-to-peer extension for Mercurial? For &gt; example, one could do sharing over things like XMPP with a suitable &gt; 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" &lt;paul.boddie&lt; at &gt;biotek.uio.no&gt; *An:* "Tom Anderson" &lt;tom.anderson&lt; at &gt;timgroup.com&gt; *Cc:* mercurial&lt; at &gt;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: </pre> Paul Boddie 2012-05-18T17:02:29 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30961 <pre>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 </pre> Wujek Srujek 2012-05-17T13:58:58 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30958 <pre>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 </pre> Wujek Srujek 2012-05-17T09:36:07 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30955 <pre>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 &lt;repo&gt;; 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 wh</pre> Eric Wing 2012-05-16T22:21:09 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30951 <pre> The following used to work - by cloning into a new directory named "repos" $ hg clone ssh://user&lt; at &gt;server/repos but now fails: $ hg clone ssh://user&lt; at &gt;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 &lt;module&gt; 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 6</pre> Jakob Hunsballe 2012-05-16T16:11:17 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30946 <pre>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: &lt;install-dir&gt;\Mercurial.ini or &lt;install-dir&gt;\hgrc.d\*.rc or HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial None of t</pre> Angel Ezquerra 2012-05-16T15:29:38 http://comments.gmane.org/gmane.comp.version-control.mercurial.general/30943 <pre>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 </pre> Wujek Srujek 2012-05-16T12:56:04 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.version-control.mercurial.general