Upcoming release of 1.4.1

[Jacob Wisor]

Hello Omair,

Omair Majid wrote:
> Hi Jakob,
> 
> On 09/12/2013 11:10 AM, Jakob Wisor wrote:
>> I have realized that IcedTea-Web's Mercurial repo does not carry any
>> branches, instead some revisions are tagged with versions.
> 
> Mercurial supports 'branches' in 3 different ways: bookmarks (analogous
> to git branches), branches and repositories. There's a fantastic
> write-up of the details of each available at:
> http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Alright, thank you for the hint. :-)

>> Just out of curiosity, and before I screw up and perhaps messing up
>> IcedTea's source control server, what's the process for pushing patches
>> to those tagged revisions? I mean, I can surely create a branch locally
>> but when I am going to push it I am unsure about the results on
>> IcedTea-Web's repo. Or, should we send Jiri patches based on a tagged
>> revision and he will do the merge?
> 
> IcedTea-Web (like most other projects on icedtea.classpath.org) uses
> separate repositories for separate branches. There's a list of all
> repositories available at:
> http://icedtea.classpath.org/hg/
> 
> For IcedTea-Web, we use the repositories at
> icedtea.classpath.org/hg/release/icedtea-web-${VERSION} for the release
> branches. 1.4 is icedtea.classpath.org/hg/release/icedtea-web-1.4/

Hmm, so there are separate repos... Well, that's one way to do it. :-) Didn't 
think of that since Mercurial has a built in branching feature. Sorry, my 
mistake, I did not look further down hgweb's page. Thanks for the tip.

To be honest, I would have preferred using Mercurial's branching feature, mainly 
because this eliminates the need for having mostly redundant clones on disk and 
it allows switching branches in-place (that's exactly what I expect from a 
distributed source control system). In combination with bookmarks Mercurial's 
branches are a cool solution indeed.

>> Well, just on a side note; This is one reason I am fed up with
>> Mercurial. No one really knows what Mercurial does or how it is going to
>> behave on specific commands.
> 
> Funny enough, since I learned mercurial first, I have the same reactions
> with git. All the commands are really obtuse in git and seem to take 5
> different flags each of which can change behavior in unexpected ways.
> And it's really easy to destroy data - the same command I to remove
> local changes removes committed changes too.

Indeed, git has become too complex or too feature rich. Sometimes less is more.

> To me mercurial seems to have a single well-defined way of doing each
> thing (other than branching, I guess).

Agreed, Mercurial does have a neat interface that is not overloaded or bloated 
with options. But, the Windows version still sucks. And, maybe it's just taste, 
but I do envy git for having a C reimplementation which has - AFAIK - become the 
official release.

> If you are missing some of the more powerful features of git (rewriting
> history, auto-paging on terminal, colours, stashing), take a look at
> some mercurial plugins ('rebase', 'pager', 'color' and 'mq' respectively).

No, don't need any fancy colors but nice to know. :-D

Okay then, I will have to clone another repo. ;-)

Thank you and happy hacking,

Jacob