Migration to Mercurial/OpenSource code hosting site
Eugene
version control system as well as also possibly migrating to the
OpenSource code hosting site (rather than in-house hosting) such as
bitbucket.org.
I've migrated from Subversion to Mercurial about a half-year ago and
since then it saved me a lot of time and enabled me to work in complex
scenarios such as developing for different branched, merging and agile
version control in general (please see http://www.infoq.com/articles/agile-version-control
for more details). I took me some time to get used to the tools at
first (with a great help from http://hginit.com) but I used them
happily ever after.
As for this project the main advantage as I see it (besides that
Mercurial repositories perform faster and more efficient than SVN's)
is enabling the collaboration with the community because anyone will
be able to hack on his own clone of the repository and suggest pulling
changes to the main development repository.
anatoly techtonik
> I would like to suggest considering migration to Mercurial distributed
> version control system as well as also possibly migrating to the
> OpenSource code hosting site (rather than in-house hosting) such as
> bitbucket.org.
You will really help Mercurial aficionados by maintaining a Mercurial
mirror on bb.
> I've migrated from Subversion to Mercurial about a half-year ago and
> since then it saved me a lot of time and enabled me to work in complex
> scenarios such as developing for different branched, merging and agile
> version control in general (please see http://www.infoq.com/articles/agile-version-control
> for more details).
Except for `hg init`, Mercurial is more complex than SVN.
> I took me some time to get used to the tools at
> first (with a great help from http://hginit.com) but I used them
> happily ever after.
How many times you tried to get used to tools?
How much time do you spend on this task total?
How can you compare it to Git, Darcs and Bazaar?
How do you cherry-pick fixes between branches in Mercurial?
> As for this project the main advantage as I see it (besides that
> Mercurial repositories perform faster and more efficient than SVN's)
You need arguments. For example, if you commit 1Gb file and then
remove it, in Mercurial you will have to download 1Gb to create your
working copy anyway. Is it efficient?
In Subversion you can checkout arbitrary dirs if you don't need the
whole project. Can you do this in Mercurial?
> is enabling the collaboration with the community because anyone will
> be able to hack on his own clone of the repository and suggest pulling
> changes to the main development repository.
It works good in theory. In practice you still need to send pull
request (instead of patch), you still need to deal with merge
conflicts, and you can't work on your branch until your changes are
pulled.
Have you tried to work with SVN from Mercurial?
--
anatoly t.
Eugene
On Apr 12, 5:12 pm, anatoly techtonik <techto...@gmail.com> wrote:
> > I would like to suggest considering migration to Mercurial distributed
> > version control system as well as also possibly migrating to the
> > OpenSource code hosting site (rather than in-house hosting) such as
> > bitbucket.org.
>
> You will really help Mercurial aficionados by maintaining a Mercurial
> mirror on bb.
> > I've migrated from Subversion to Mercurial about a half-year ago and
> > since then it saved me a lot of time and enabled me to work in complex
> > scenarios such as developing for different branched, merging and agile
>
> Except for `hg init`, Mercurial is more complex than SVN.
>
> > I took me some time to get used to the tools at
>
> How many times you tried to get used to tools?
> How much time do you spend on this task total?
console tools in basic scenarios.
However searching for and trying different GUI tools for Windows took
me a few days but now I consider TortoiseHg (http://
tortoisehg.bitbucket.org/) and VisualHG (http://
visualhg.codeplex.com/) Visual Studio's plug-in the best combination
for my uses.
Then it look me a week or two to read to read while commuting to work
http://hgbook.red-bean.com/ for deeper understanding and advanced uses
of Mercurial.
In contrast when I converted one of our in-house projects to Mercurial
my colleague started using it straight away even without prior
knowledge of Mercurial. (but with some tips from me.)
> How can you compare it to Git, Darcs and Bazaar?
thoughts I had when choosing Mercurial over other DVCS:
- Out of all DCVS Git and Mercurial appears to have the more support
from the community and have better performance (old, but
http://ldn.linuxfoundation.org/article/dvcs-round-one-system-rule-them-all-part-3);
- Don't like that with Git I need to perform some kind of housekeeping
on the repository from time to time;
- Highly subjective: Joel Spolsky advocates Mercurial and uses it in
FogBugz;
- Google's code.google.com and Microsoft's codeplex.com out of all
DVCS supports only Mercurial; (not a huge deal but for me it tells of
'big players' support)
- For Git for Windows appears to come with a bunch of different GNU
utilities such as bash, make, gawk and grep;
- Learning curve for Git appeared to be more difficult than for
Mercurial;
> How do you cherry-pick fixes between branches in Mercurial?
(http://mercurial.selenic.com/wiki/TransplantExtension) with you don't
want to merge it with the whole branch.
>
> > As for this project the main advantage as I see it (besides that
> > Mercurial repositories perform faster and more efficient than SVN's)
>
> You need arguments. For example, if you commit 1Gb file and then
> remove it, in Mercurial you will have to download 1Gb to create your
> working copy anyway. Is it efficient?
in size than due to compression)
but in practice one can get rid of the changeset its descendants from
the history using `hg strip`. (http://mercurial.selenic.com/wiki/
Strip)
However I don't think that storing large binary files in the version
control is a good idea anyway. There are some approaches (http://
mercurial.selenic.com/wiki/BigfilesExtension) still to handle those
with Mercurial too.
As for storage efficiency I've got some sizes in regards to the
FarManager's repository:
- Clone of SVN repository (svnsync'ed): 151 MB;
- Mercurial repository (without working directory): 31.4 MB;
- Checked out trunk of the SVN repository (with all those .svn
directories): 73.8 MB;
- Mercurial repository with working directory: 68.0 MB;
It was taking me more than 2 hours to checkout the entire SVN repo
(took about 3 minutes to clone from BitBucket for Mercurial) with all
tags and branches so I cancelled it before it finished... (given I had
svnsync'ed local copy)
> In Subversion you can checkout arbitrary dirs if you don't need the
> whole project. Can you do this in Mercurial?
entire repository.
You can have subrepositories (http://mercurial.selenic.com/wiki/
Subrepository) though.
However (besides that Mercurial works pretty fast on even large
repositories) I think it makes sense to have the entire project so all
changes are visible to everybody.
Probably it is more of ideology question whether you have one big
integral project of a few projects with small cohesion. Possibly if
all parts are mainly maintained by the same people it is just easier
to have one repository to benefit merging capabilities.
> > is enabling the collaboration with the community because anyone will
> > be able to hack on his own clone of the repository and suggest pulling
> > changes to the main development repository.
>
> It works good in theory. In practice you still need to send pull
> request (instead of patch), you still need to deal with merge
> conflicts, and you can't work on your branch until your changes are
> pulled.
http://mercurial.selenic.com/wiki/MqExtension - which is very
powerful).
And you can continue working on your branch while your changes are
reviewed -- that just would be that any consequent changes will have
to be reviewed separately as well.
> Have you tried to work with SVN from Mercurial?
products for a few months (before I had an opportunity to migrate the
whole project to Mercurial).
So we had master SVN repo but I used it from Mercurial via
hgsubversion extension (http://mercurial.selenic.com/wiki/
HgSubversion).
I was able to commit changes to Mercurial and send them back to SVN
but unfortunately in this fashion you can't use the Mercurial's
merging freely because you wan't be able to push back merged changes
-- I found a procedure to work around it but it is rather difficult to
use safely.
> --
> anatoly t.
anatoly techtonik
> Please see my comments below.
>
> On Apr 12, 5:12 pm, anatoly techtonik <techto...@gmail.com> wrote:
>> On Tue, Apr 12, 2011 at 3:59 PM, Eugene <eug.bara...@gmail.com> wrote:
>> > I would like to suggest considering migration to Mercurial distributed
>> > version control system as well as also possibly migrating to the
>> > OpenSource code hosting site (rather than in-house hosting) such as
>> > bitbucket.org.
>>
>> You will really help Mercurial aficionados by maintaining a Mercurial
>> mirror on bb.
>
> Converted to https://bitbucket.org/regent/farmanager
Icy. Is it synchronized with Subversion automatically?
>> How many times you tried to get used to tools?
> Once was enough for me.
>
>> How much time do you spend on this task total?
> A few hours of reading on hginit.com made me quite comfortable with
> console tools in basic scenarios.
Imagine that with the prior Subversion knowledge it still took few
hours to get basics. Most developers don't have time for that. That's
why it is better to maintain a mirror for playing.
> However searching for and trying different GUI tools for Windows took
> me a few days but now I consider TortoiseHg (http://
> tortoisehg.bitbucket.org/) and VisualHG (http://
> visualhg.codeplex.com/) Visual Studio's plug-in the best combination
> for my uses.
You've forgot MercurialEclipse.
> Then it look me a week or two to read to read while commuting to work
> http://hgbook.red-bean.com/ for deeper understanding and advanced uses
> of Mercurial.
>
> In contrast when I converted one of our in-house projects to Mercurial
> my colleague started using it straight away even without prior
> knowledge of Mercurial. (but with some tips from me.)
For open source projects I use Mercurial Queues more than plain HG,
but it is a black art for starters.
>> How do you cherry-pick fixes between branches in Mercurial?
> Particular changesets from a different branch can be transplanted
> (http://mercurial.selenic.com/wiki/TransplantExtension) with you don't
> want to merge it with the whole branch.
That statement is not really clear. I need to merge branches together
at some point and won't get a conflict at the cherry-picked change. Is
that possible with transplant?
>>
>> > As for this project the main advantage as I see it (besides that
>> > Mercurial repositories perform faster and more efficient than SVN's)
>>
>> You need arguments. For example, if you commit 1Gb file and then
>> remove it, in Mercurial you will have to download 1Gb to create your
>> working copy anyway. Is it efficient?
> In theory DVCS you'll have to download that 1GB file (probably smaller
> in size than due to compression)
> but in practice one can get rid of the changeset its descendants from
> the history using `hg strip`. (http://mercurial.selenic.com/wiki/
> Strip)
When you strip something from your public bb repository, all revisions
after the stripped ones in other clones will become invalid and
merging them will yield conflicts. Right?
> However I don't think that storing large binary files in the version
> control is a good idea anyway. There are some approaches (http://
> mercurial.selenic.com/wiki/BigfilesExtension) still to handle those
> with Mercurial too.
>
> As for storage efficiency I've got some sizes in regards to the
> FarManager's repository:
> - Clone of SVN repository (svnsync'ed): 151 MB;
> - Mercurial repository (without working directory): 31.4 MB;
> - Checked out trunk of the SVN repository (with all those .svn
> directories): 73.8 MB;
> - Mercurial repository with working directory: 68.0 MB;
> It was taking me more than 2 hours to checkout the entire SVN repo
> (took about 3 minutes to clone from BitBucket for Mercurial) with all
> tags and branches so I cancelled it before it finished... (given I had
> svnsync'ed local copy)
Thanks for the stats - they are really helpful. I can see the
advantages for Far Manager project right away even without
subprojects.
>> > is enabling the collaboration with the community because anyone will
>> > be able to hack on his own clone of the repository and suggest pulling
>> > changes to the main development repository.
>>
>> It works good in theory. In practice you still need to send pull
>> request (instead of patch), you still need to deal with merge
>> conflicts, and you can't work on your branch until your changes are
>> pulled.
> You can send patches too (using Mercurial Queues extension -
> http://mercurial.selenic.com/wiki/MqExtension - which is very
> powerful).
> And you can continue working on your branch while your changes are
> reviewed -- that just would be that any consequent changes will have
> to be reviewed separately as well.
You send a pull request for the whole branch - not for specific
revision range. How can a person see what changes are ready to be
pulled and what are the part of your further work?
>> Have you tried to work with SVN from Mercurial?
> Yes, I tried. In fact I was working my one of our in-house commercial
> products for a few months (before I had an opportunity to migrate the
> whole project to Mercurial).
> So we had master SVN repo but I used it from Mercurial via
> hgsubversion extension (http://mercurial.selenic.com/wiki/
> HgSubversion).
> I was able to commit changes to Mercurial and send them back to SVN
> but unfortunately in this fashion you can't use the Mercurial's
> merging freely because you wan't be able to push back merged changes
> -- I found a procedure to work around it but it is rather difficult to
> use safely.
The same pain. These workflows need more pictures than words, because
it is hard to notice missing parts.
Have you seen how go-lang people are using Mercurial? It is a single
line of development. I find it very convenient in SVN for reviewing
changes and browsing history.
Eugene
> > Please see my comments below.
>
> > On Apr 12, 5:12 pm, anatoly techtonik <techto...@gmail.com> wrote:
> >> On Tue, Apr 12, 2011 at 3:59 PM, Eugene <eug.bara...@gmail.com> wrote:
> >> > I would like to suggest considering migration to Mercurial distributed
> >> > version control system as well as also possibly migrating to the
> >> > OpenSource code hosting site (rather than in-house hosting) such as
> >> > bitbucket.org.
>
> >> You will really help Mercurial aficionados by maintaining a Mercurial
> >> mirror on bb.
>
> > Converted to https://bitbucket.org/regent/farmanager
>
> Icy. Is it synchronized with Subversion automatically?
> >> How many times you tried to get used to tools?
> > Once was enough for me.
>
> >> How much time do you spend on this task total?
> > A few hours of reading on hginit.com made me quite comfortable with
> > console tools in basic scenarios.
>
> Imagine that with the prior Subversion knowledge it still took few
> hours to get basics. Most developers don't have time for that. That's
> why it is better to maintain a mirror for playing.
from centralized SVN-like systems, as SVN-like systems were step from
manual copying/archiving to maintain source code versions.
So of course we are all busy but as for me DVCS was one of the
greatest tools I've found over the last several years.
With DVCS you can have versioned documents on your home computer
without having to setup any central repository anywhere.
Also you can safely work on a project without an Internet connection
and only pull/push once you have a chance.
So IMHO it is worth having Mercurial on your toolbelt as a general
purpose tool.
> > However searching for and trying different GUI tools for Windows took
> > me a few days but now I consider TortoiseHg (http://
> > tortoisehg.bitbucket.org/) and VisualHG (http://
> > visualhg.codeplex.com/) Visual Studio's plug-in the best combination
> > for my uses.
>
> You've forgot MercurialEclipse.
> > Then it look me a week or two to read to read while commuting to work
>
> > In contrast when I converted one of our in-house projects to Mercurial
> > my colleague started using it straight away even without prior
> > knowledge of Mercurial. (but with some tips from me.)
>
> For open source projects I use Mercurial Queues more than plain HG,
> but it is a black art for starters.
use MQ
but even without MQ changesets can be `bundled` and sent over an e-
mail, for instance.
> >> How do you cherry-pick fixes between branches in Mercurial?
> > Particular changesets from a different branch can be transplanted
> > (http://mercurial.selenic.com/wiki/TransplantExtension) with you don't
> > want to merge it with the whole branch.
>
> That statement is not really clear. I need to merge branches together
> at some point and won't get a conflict at the cherry-picked change. Is
> that possible with transplant?
code was changed after/before
the previously cherry-picked changeset. Much easier when you can
actually 'cherry-pick' changeset up
to some revision.
From my experience the best way to minimize conflicts is to work at
one feature/fix/enhancement at a time
so it will always make so merge the main branch with another as whole.
> >> > As for this project the main advantage as I see it (besides that
> >> > Mercurial repositories perform faster and more efficient than SVN's)
>
> >> You need arguments. For example, if you commit 1Gb file and then
> >> remove it, in Mercurial you will have to download 1Gb to create your
> >> working copy anyway. Is it efficient?
> > In theory DVCS you'll have to download that 1GB file (probably smaller
> > in size than due to compression)
> > but in practice one can get rid of the changeset its descendants from
> > the history using `hg strip`. (http://mercurial.selenic.com/wiki/
> > Strip)
>
> When you strip something from your public bb repository, all revisions
> after the stripped ones in other clones will become invalid and
> merging them will yield conflicts. Right?
- When stripped in 'main' repository you should ask all users to
perform the same action.
(BB suggests that on the dashboard but it is up to users whether to
run it or not)
- Merging with something after that 1GB cset won't fail but
effectively bring
back that 1GB again; (Mercurial will forget about that cset ever been
there so will treat as a new)
- If you need to have descendants of that 1GB cset then you'll have to
play with MQ.
> > And you can continue working on your branch while your changes are
> > reviewed -- that just would be that any consequent changes will have
> > to be reviewed separately as well.
>
> You send a pull request for the whole branch - not for specific
> revision range. How can a person see what changes are ready to be
> pulled and what are the part of your further work?
which changes are worth reviewing/pulling.
> >> Have you tried to work with SVN from Mercurial?
> > Yes, I tried. In fact I was working my one of our in-house commercial
> > products for a few months (before I had an opportunity to migrate the
> > whole project to Mercurial).
> > So we had master SVN repo but I used it from Mercurial via
> > hgsubversion extension (http://mercurial.selenic.com/wiki/
> > HgSubversion).
> > I was able to commit changes to Mercurial and send them back to SVN
> > but unfortunately in this fashion you can't use the Mercurial's
> > merging freely because you wan't be able to push back merged changes
> > -- I found a procedure to work around it but it is rather difficult to
> > use safely.
>
> The same pain. These workflows need more pictures than words, because
> it is hard to notice missing parts.
useless in general.
I think it is not that bad when you use MQ but still too advanced to
call it 'basic Mercurial use'.
Personally I've got a lot of interesting experience inventing all
those workflows
but it is too exotic for anyone else to like.
> Have you seen how go-lang people are using Mercurial? It is a single
> line of development. I find it very convenient in SVN for reviewing
> changes and browsing history.
review system.
I agree that from other point of view single line of development is
convenient for browsing history,
but from the other side sometimes different lines of development makes
perfect sense.
E.g. main development on 'default' branch while hotfixes to 'stable'.
Or alpha development of version 'application-version-3'
while still active development of 'application-version-2'.
anatoly techtonik
>>
>> > Converted to https://bitbucket.org/regent/farmanager
>>
>> Icy. Is it synchronized with Subversion automatically?
>
> I have to run a script to get the new changes.
Is it some standard script? What are the limitations of this conversion?
>> Imagine that with the prior Subversion knowledge it still took few
>> hours to get basics. Most developers don't have time for that. That's
>> why it is better to maintain a mirror for playing.
>
> Sure. But I think that DVCS, to a certain degree, is the next step
> from centralized SVN-like systems, as SVN-like systems were step from
> manual copying/archiving to maintain source code versions.
I'd say it is a half step. The workflow with DVCS is still more
complicated than with SVN tools and sometimes it wastes more time than
necessary if you don't completely understand how system works
(although not as much as merges in SVN). I'd still prefer central SVN
and satellite HG/Git/Bazaar whatever repos if it was possible. I
proposed creating intechangeable intermediate changeset format, but
neither HG nor SVN developers are interested in wasting time on that.
I've been told that Bazaar folks invented similar internal format, but
I haven't seen it. So.. until DVCS do not allow to speak to each
other, it is a half step back.
> So of course we are all busy but as for me DVCS was one of the
> greatest tools I've found over the last several years.
> With DVCS you can have versioned documents on your home computer
> without having to setup any central repository anywhere.
So basically, it is `hg init`, right? =)
> Also you can safely work on a project without an Internet connection
> and only pull/push once you have a chance.
I've lost a lot of code due to HDD crash thanks to that. I even miss
some info now.
> So IMHO it is worth having Mercurial on your toolbelt as a general
> purpose tool.
Agree.
> I totally agree that one without deeper understanding shouldn't really
> use MQ
> but even without MQ changesets can be `bundled` and sent over an e-
> mail, for instance.
Could be a useful practice, but I suspect Far developers prefer forum.
>> >> How do you cherry-pick fixes between branches in Mercurial?
>> > Particular changesets from a different branch can be transplanted
>> > (http://mercurial.selenic.com/wiki/TransplantExtension) with you don't
>> > want to merge it with the whole branch.
>>
>> That statement is not really clear. I need to merge branches together
>> at some point and won't get a conflict at the cherry-picked change. Is
>> that possible with transplant?
>
> It depends. Usually it will have a conflict if the same area of the
> code was changed after/before
> the previously cherry-picked changeset. Much easier when you can
> actually 'cherry-pick' changeset up
> to some revision.
If you pull all changesets up to some revision, how is that different
from merge?
> From my experience the best way to minimize conflicts is to work at
> one feature/fix/enhancement at a time
> so it will always make so merge the main branch with another as whole.
It is not always possible, unfortunately. Not all branches are feature
branches and you still need to port fixes between them, e.g. for
urgent deployment on production.
> - If you need to have descendants of that 1GB cset then you'll have to
> play with MQ.
I thought that 'strip' handles this automatically, i.e. if there are
descendants, it moves 1GB to the first descendant cset.
>> Have you seen how go-lang people are using Mercurial? It is a single
>> line of development. I find it very convenient in SVN for reviewing
>> changes and browsing history.
> Just checked it and looks like they have a quite interesting code
> review system.
There is a custom Mercurial extensions for preparing change for review
and then it is send to Rietveld server. Rietveld supports various
VCSes, but was made primarily for SVN, so it still have a lot of
issues to close for proper DVCS support. Chromium developers use it
too.
Eugene
> On Wed, Apr 13, 2011 at 2:09 AM, Eugene <eug.bara...@gmail.com> wrote:
>
> >> > Converted tohttps://bitbucket.org/regent/farmanager
> >> Icy. Is it synchronized with Subversion automatically?
>
> > I have to run a script to get the new changes.
>
> Is it some standard script? What are the limitations of this conversion?
http://hgbook.red-bean.com/read/migrating-to-mercurial.html.
Besides having some 'hanging' revisions as far as the Mercurial
repository is readonly I don't see any limitations.
(Pushing changes back to SVN is not possible with this layout.)
>
> >> Imagine that with the prior Subversion knowledge it still took few
> >> hours to get basics. Most developers don't have time for that. That's
> >> why it is better to maintain a mirror for playing.
>
> > Sure. But I think that DVCS, to a certain degree, is the next step
> > from centralized SVN-like systems, as SVN-like systems were step from
> > manual copying/archiving to maintain source code versions.
>
> I'd say it is a half step. The workflow with DVCS is still more
> complicated than with SVN tools and sometimes it wastes more time than
> necessary if you don't completely understand how system works
> (although not as much as merges in SVN). I'd still prefer central SVN
> and satellite HG/Git/Bazaar whatever repos if it was possible. I
> proposed creating intechangeable intermediate changeset format, but
> neither HG nor SVN developers are interested in wasting time on that.
> I've been told that Bazaar folks invented similar internal format, but
> I haven't seen it. So.. until DVCS do not allow to speak to each
> other, it is a half step back.
>
> > So of course we are all busy but as for me DVCS was one of the
> > greatest tools I've found over the last several years.
> > With DVCS you can have versioned documents on your home computer
> > without having to setup any central repository anywhere.
>
> So basically, it is `hg init`, right? =)
> > Also you can safely work on a project without an Internet connection
> > and only pull/push once you have a chance.
>
> I've lost a lot of code due to HDD crash thanks to that. I even miss
> some info now.
convenient too.
(Let's say your ISP just have an outage for a week, it's still better
to have local version control than none; besides backups
usually are just trivial `hg clone` to the backup media)
> > So IMHO it is worth having Mercurial on your toolbelt as a general
> > purpose tool.
>
> Agree.
where the particular bug you noticed
but you know it wasn't there before was introduced. (You still have to
test whether the bug appears in a
particular cset yourself but Mercurial will ask you to test a few a
necessary.)
> > I totally agree that one without deeper understanding shouldn't really
> > use MQ
> > but even without MQ changesets can be `bundled` and sent over an e-
> > mail, for instance.
>
> Could be a useful practice, but I suspect Far developers prefer forum.
> >> >> How do you cherry-pick fixes between branches in Mercurial?
> >> > Particular changesets from a different branch can be transplanted
> >> > (http://mercurial.selenic.com/wiki/TransplantExtension) with you don't
> >> > want to merge it with the whole branch.
>
> >> That statement is not really clear. I need to merge branches together
> >> at some point and won't get a conflict at the cherry-picked change. Is
> >> that possible with transplant?
>
> > It depends. Usually it will have a conflict if the same area of the
> > code was changed after/before
> > the previously cherry-picked changeset. Much easier when you can
> > actually 'cherry-pick' changeset up
> > to some revision.
>
> If you pull all changesets up to some revision, how is that different
> from merge?
> > From my experience the best way to minimize conflicts is to work at
> > one feature/fix/enhancement at a time
> > so it will always make so merge the main branch with another as whole.
>
> It is not always possible, unfortunately. Not all branches are feature
> branches and you still need to port fixes between them, e.g. for
> urgent deployment on production.
conflict resolution later. (Which
is much easier that with SVN in contrast.)
Still much better than no branches at all. (At with SVN unless to want
to sign-in to the merge-hell later.)
> > - If you need to have descendants of that 1GB cset then you'll have to
> > play with MQ.
>
> I thought that 'strip' handles this automatically, i.e. if there are
> descendants, it moves 1GB to the first descendant cset.
> >> Have you seen how go-lang people are using Mercurial? It is a single
> >> line of development. I find it very convenient in SVN for reviewing
> >> changes and browsing history.
> > Just checked it and looks like they have a quite interesting code
> > review system.
>
> There is a custom Mercurial extensions for preparing change for review
> and then it is send to Rietveld server. Rietveld supports various
> VCSes, but was made primarily for SVN, so it still have a lot of
> issues to close for proper DVCS support. Chromium developers use it
> too.
me tons
of time just to get to the latest revision...