tags:

views:

193

answers:

4

Hi,

Just started working with Mercurial a few days ago and there's something I don't understand.

I have an experimental thing I want to do, so the normal thing to do would be to clone my repository, work on the clone and if eventually I want to keep those changes, I'll push them to my main repository.

Problem is cloning my repository takes alot of time (we have alot of code) and just compiling the cloned copy would take up to an hour.
So I need to somehow work on a different repository but still in my original working copy.

Enter local branches.

Problem is just creating a local branch takes forever, and working with them isn't all that fun either. Because when moving between local branches doesn't "revert" to the target branch state, I have to issue a hg purge (to remove files that were added in the moved from branch) and then hg update -c (to revert modified files in the moved from branch). (note: I did try PK11 fork of local branch extension, it a simple local branch creation crashes with an exception)

At the end of the day, this is just too complex. What are my options?

A: 

how long does cloning a local repo take?

it sounds like you build process might be the weak link to me - perhaps you need something like ccache? so that you can clone and build quickly

jk
cloning it takes around 5-10 minutes, the problem is compiling it and setting up other necessary stuff. compiling with incredibuild with a combined power reaching 50ghz takes around 45 minutes. unfortunately `ccache` doesn't work with visual studio
Zack
i can't tell from the web if incredibuild has the ability to cache builds, if its taking that long i would assume not (maybe check its docs?). as a work around you might get away with copying the obj and bin dirs when you clone.
jk
as far as i know incredibuild can't cache builds but i think you're slightly missing the point. copying the working copy is just too much work for me. even if my build wasn't taking so long there are some other stuff that require configuration before i can start working in a completely different working copy. so the concept of sharing a working copy between repositories, and a simple way of moving back and forth seems to be least painful solution.
Zack
if you require manual configuration after cloning i'd say your build process isn't automated enough, but if you are happy with it and using mq then thats fine
jk
A: 

couldn't you make your experiments on top of your existing clone and when you want to make some changes to the main line go back and update to the last revision before you started the experiments?

domruf
+4  A: 

There are several ways of working with local branches besides cloning:

  • Bookmarks
  • Named branches
  • Anonymous branches

You may be interested in reading a very insightful guide to branching in Mercurial. I guess the bookmarks extension is the most appropriate way of branching in the context you've described.

Andrey Vlasovskikh
it does look like bookmarks are the way to go but what happens if I decide my experimental thingy isn't good? it's now in my repository
Zack
@Zack You can enable the **mq** extension and run the `hg strip` command to get rid of unpublished branches you don't need any longer.
Andrey Vlasovskikh
i'm not sure any of these solve the problem because it sounds like updating and re-building the working copy is what takes a long time, not really the clone
jk
@jk: while re-building after an update will take time, it will take significantly less than a complete re-build. this is something i'm willing to live with and there's really no way to avoid it.
Zack
@Andrey, `hg strip` is excellent for my purposes, i will try this for a bit and see if it works well
Zack
A: 

Probably not the answer you want to hear, but I would say maybe you should consider splitting your repository into a little more manageable chunks :). E.g. does that documentation and those design files really need to be included in the same repository, does that editor tool not deserve its own repository, etc.

Because as cloning creates hard links, it’s pretty much already as fast as it can get; if cloning takes 5-10 minutes already, making a file system copy must be even worse. (Tip: keep in mind hg clone -U if you do not need a working copy, it will be much much faster.)

Otherwise, yeah, anonymous branches with bookmarks is the usual way to do in-place switching.

Laurens Holst
actually we have almost no documentation in the repository, it's mostly our source code and 3rdparty. we could move the 3rdparty to another repository but subrepos support in mercurial is a work in progress atm so i'm not sure if it's such a good idea.
Zack
As far as I know the subrepos feature is a work in progress in the sense that it has not been fully integrated with all commands and extensions in Mercurial (I would give you a quote if I remembered where I read it). However the feature is stable in regards of compatibility.
Laurens Holst
Found it — http://stackoverflow.com/questions/2213709/is-the-subprepos-feature-in-mercurial-1-4-x-ready-for-production-use
Laurens Holst