http://permalink.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://permalink.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://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30985 <pre>On Mon, May 21, 2012 at 4:52 PM, Mihamina Rakotomandimby &lt;mihamina&lt; at &gt;rktmb.org&gt; wrote: What version of TortoiseHg are you using? I just tried it and it works fine on my end with the latest version. Cheers, Angel </pre> Angel Ezquerra 2012-05-21T15:13:58 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30984 <pre>On Mon, May 21, 2012 at 7:52 AM, Mihamina Rakotomandimby &lt;mihamina&lt; at &gt;rktmb.org You can indeed merge non-head revisions. You might want to take up this error message with the TortoiseHg developers, since it's not Mercurial that's complaining. </pre> Bryan O'Sullivan 2012-05-21T14:58:48 http://permalink.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://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30982 <pre>Ken Halprin wrote, On 05/20/2012 10:57 PM: That seems like a nice structure. You might also want to put your client application in the same repo, depending on how tightly coupled they are and if they follow the same release cycle. That will make branching and introduction of new protocol features much simpler. ... but this all depends on the size of your repo. If the combined repo gets too big to be manageable then it might be better to split it up somehow. /Mads Thanks. I do plan on having the client app in the repository too, for that exact reason. We may introduce new features or capabilities that need to track together. I wasn't so concerned about the structure of that part of the repo though since the client doesn't share much code among its modules. Ken </pre> Ken Halprin 2012-05-20T22:28:03 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30981 <pre>Ken Halprin wrote, On 05/20/2012 10:57 PM: That seems like a nice structure. You might also want to put your client application in the same repo, depending on how tightly coupled they are and if they follow the same release cycle. That will make branching and introduction of new protocol features much simpler. ... but this all depends on the size of your repo. If the combined repo gets too big to be manageable then it might be better to split it up somehow. /Mads </pre> Mads Kiilerich 2012-05-20T22:11:23 http://permalink.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://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30979 <pre>Thanks for all the replies. There were too many replies to reply to individual posts, but let me make a few points. * Cloned vs. named branches. I guess you're right, perhaps cloned branches are not the "official" position any more. I probably got that from the Red Bean book. Is there any way to get Bryan O'Sullivan to change the Red Bean website to have some sort of disclaimer that it should probably not in any way be considered a definitive guide anymore as I've run into several cases now where it has questionable or outright wrong information? Although the mercurial team itself uses named branches, having "default" and "stable" where stable is regularly merged with default is hardly a heavy use of it. And as older branches diverge more and more from the newer ones, the delta algorithm performs worse and worse. * Authentication, sharing among designers before pushing to main server In the end, I suppose my point is this. In order to allow a DVCS-style workflow in a secure environment, you've got to eit</pre> Stephen Morton 2012-05-20T19:11:14 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30978 <pre>On Sun, May 13, 2012 at 9:16 AM, Giorgos Keramidas &lt;keramida&lt; at &gt;ceid.upatras.gr Yes, I agree with you Giorgos. I think you've summarized a bunch of the issues well. Conceptually, pushlog information is metadata associated with each changeset, or perhaps with groups of changesets. But because of the immutability of Mercurial changesets, it really has to be stored externally from the changeset itself (because of the fact that it changes every commit/incoming). Similarly, it can't really be stored in extra changesets as the pushlog changesets would have to be rewritten. I guess it would be possible to have a secondary repo of changesets that recorded pushlog information that mirrored the primary repo; but I'm sure this is fraught with extension and other technical issues. Mozilla and SonicHg both store their pushlog information in a sqlite database, which is to me inelegant --because you've got part of your essential repo metadata in revlogs and part in sqlite-- but is nice and simple. SonicHg has a nice simple</pre> Stephen Morton 2012-05-20T18:08:01 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30977 <pre>Eric Wing wrote, On 05/17/2012 12:21 AM: More exactly: update works in repos where the 'default' path points at your central repo (or wherever you got the changeset that referenced the new subrepo revision). A consequence of using subrepos is that they will be pulled on demand and thus is more suitable for a centralized workflow than for a DVCS workflow. Yes, a bare pull is rarely a good idea when using subrepos. Always use pull -u. You can also use "hg up --config paths.default=therightpath" to tell Mercurial what the default location for missing subrepos is. A better way to do that would be to set an invalid 'default-push' path. Please see http://mercurial.selenic.com/wiki/Subrepository and help improving it. /Mads </pre> Mads Kiilerich 2012-05-19T13:03:08 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30976 <pre> Just checked: It's the same on Windows XP. </pre> Adrian Buehlmann 2012-05-19T09:23:49 http://permalink.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://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30974 <pre> Looking at this again, I think you should probably create an extra user account for running the web server and run the service under that user, as explained at http://httpd.apache.org/docs/2.4/platform/windows.html#winsvc after "It is recommended that users create a separate account for running Apache service(s)". A user has its own "per user" environment variables. So you could set HGRCPATH there for that user only. As the Apache docs suggest, you'll need to add the "Logon as a service" security policy to that user, so that said user can run programs as a service. On Windows 7, I believe this can be achieved via Control Panel -&gt; Administrative Tools -&gt; Local Security Policy. Then in the dialog "Local Security Policy", under "Local Policies", select "User Rights Assignment" then in the long list of policies on the right half, select the "Log on as a service" policy, then "Properties" from the context menu of that item. This will open a dialog with a list of users or groups having that policy. There you</pre> Adrian Buehlmann 2012-05-18T14:06:56 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30973 <pre> This is really intended for wsgi in IIS on Windows, and is slightly out of date, but take a look at the file hgwebdir_wsgi.py in contrib/win32 of the source tree. Where I work, we use a script based on that to serve our repository forrests. I am not sure how any of this applies to the Apache setup, though. -Sune </pre> Sune Foldager 2012-05-18T13:11:27 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30972 <pre> That's probably a good argument for preferring using HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial over setting HGRCPATH system wide. scmutil.systemrcpath() looks into HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial only iff there's neither a mercurial.ini file next to the hg.exe, nor a hgrc.d directory. http://selenic.com/repo/hg/file/stable/mercurial/scmutil.py#l469 For added security, you could also make the web server config file readable by the SYSTEM user only (file read permissions). Globally defining HGRCPATH is indeed probably not such a good idea. </pre> Adrian Buehlmann 2012-05-18T13:00:02 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30971 <pre> Thank you Adrian, that is very helpful. I tried setting the HGRCPATH environment variable and that works as expected. I have two problems though: 1. There seems to be no way to set some config that only applies to the SYSTEM user, which is the one running the apache web server. This means that any user logged into the server that will use mercurial will use (and see) the configuration used by the web server. 2. When using HGRCPATH the default "osrcpath" is lost. It would be neat to have a way to refer to the default osrcpath, in order to simply add an extra path where the configuration must be looked for. Maybe we could add a _special path_ that when added to the HGRCPATH would be expanded as osrcpath()? (e.g. $hgosrcpath). Cheers, Angel </pre> Angel Ezquerra 2012-05-18T12:08:10 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30970 <pre> [..] Seems so. Note that you can specify multiple paths there (see 'hg help config' for the details). Except that there is also the environment variable HGRCPATH, which is used in scmutil.py, function rcpath() (line 409): http://selenic.com/repo/hg/file/stable/mercurial/scmutil.py#l409 The environment variables are documented in 'hg help environment' or here: http://selenic.com/repo/hg/help/environment which says: HGRCPATH A list of files or directories to search for configuration files. Item separator is ":" on Unix, ";" on Windows. If HGRCPATH is not set, platform default search path is used. If empty, only the .hg/hgrc from the current repository is read. For each element in HGRCPATH: - if it's a directory, all files ending with .rc are added - otherwise, the file itself will be added Yes. But that's a separate configuration. See 'hg help hgweb' or http://selenic.com/repo/hg/help/hgweb Quoting: This file uses the</pre> Adrian Buehlmann 2012-05-18T11:23:13 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30969 <pre> For a mercurial source package you need to run hg from the python scripts directory: C:\Users\mikew&gt;set path=%path%;c:\Python26\scripts C:\Users\mikew&gt;hg showconfig --debug read config from: C:\Users\mikew\mercurial.ini read config from: C:\Users\mikew\.hgrc read config from: C:\Users\mikew\mercurial.ini read config from: C:\Users\mikew\.hgrc none: ui.verbose=False none: ui.debug=True none: ui.quiet=False Not relevant to your original question, but an interesting question is why source the same user config files twice? The python call os.path.expanduser() uses %USERPROFILE% if %HOME% is not defined (fairly typical for Windows devs without a *nix background) so hg ends up using %USERPROFILE% twice. A check that the result from os.path.expanduser() and os.environ.get('USERPROFILE') are different (ignoring case of course) would solve it if it was deemed important. HTH </pre> Mike Williams 2012-05-18T09:20:06 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30968 <pre> Because Draft status doesn't change on a pull, I could amend my primary repository after syncing to a clone (the backup on an external drive). Re-pulling on the clone of course now has both the amended and original commits as separate heads. That's okay for me in this situation; eventually I'll merge them and have the primary, the backup, and the portable clone all agreeing about what the heads are. So I don't see it as a problem, but it is something that --amend users should keep in mind. (I'm also reading through the Evolve pages; sounds like a good project to keep an eye on.) </pre> Dave S 2012-05-17T23:48:25 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30967 <pre> Yes, however we currently deem this to be too confusing a default because: - hg help -&gt; help is paged - hg update -h -&gt; help is NOT paged - hg badcommand -&gt; help is NOT paged - hg update --bad -&gt; help is NOT paged When we fix the infrastructure as in this bug: http://bz.selenic.com/show_bug.cgi?id=3397 ..we'll consider making it a pager default. </pre> Matt Mackall 2012-05-17T22:45:07 http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/30966 <pre>This does work, help is paged, for example, when I add this in my hgrc: [pager] pager = less -FRSX attend = I'm on mercurial 2.2.1. The question is: do you find it a good idea to add the help command to the default attend list, as there are commands with long descriptions and paging them by default would help a lot in my humble opinion. wujek On Thu, May 17, 2012 at 10:31 PM, Patrick Mézard &lt;patrick&lt; at &gt;mezard.eu&gt; wrote: </pre> Wujek Srujek 2012-05-17T20:54:56 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.version-control.mercurial.general