title: Mercurial practices: use with IDEs and scalability
body: <p>I am not an experimented user of SCM tools, even though I am convinced of their usefulness, of course.
  I used some obscure commercial tool in a former job, Perforce in the current one, and played a bit with TortoiseSVN for my little personal projects, but I disliked having lot of .svn folders all over the place, making searches, backups and such more difficult.
  Then I discovered the interest of distributed SCM and I chose to go the apparently simpler (than git) Mercurial way, still for my personal, individual needs. I am in the process of learning to use it properly, having read part of the wiki and being in the middle of the excellent PDF book.</p>
  
  <p>I see often repeated, for example in <a href="http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices?highlight=%28practices%29" rel="nofollow noreferrer" title="Mercurial working practices">Mercurial working practices</a>, "<em>don't hesitate to use multiple trees locally. Mercurial makes this fast and light-weight.</em>" and "<em>for each feature you work on, create a new tree.</em>".
  These are interesting and sensible advices, but they hurt a bit my little habits with centralized SCM, where we have a "holy" central repository where branches are carefully planned (and handled by administrators), changelists must be checked by (senior) peers and must not break the builds, etc. :-) Starting to work on a new branch takes quite some time...</p>
  
  <p>So I have two questions in the light of above:</p>
  
  <ul>
  <li><p>How practical is it to do lot of clones, in the context of IDEs and such? What if the project has configuration/settings files, makefiles or Ant scripts or shell scripts or whatever, needing path updates? (yes, probably a bad idea...) For example, in Eclipse, if I want to compile and run a clone, I have to do yet another project, tweaking the Java build path, the Run/Debug targets, and so on. Unless an Eclipse plugin ease that task. Do I miss some facility here?</p></li>
  <li><p>How do that scale? I have read Hg is OK for large code bases, but I am perplex. At my job, we have a Java application (well, several around a big common kernel) of some 2 millions of lines, weighting some 110MB for code alone. Doing a clean compile on my old (2004) Windows workstation takes some 15 minutes to generate the 50MB of class files! I don't see myself cloning the whole project to change 3 files. So what are the practices here?</p></li>
  </ul>
  
  <p>I haven't yet seen these questions addressed in my readings, so I hope this will make a useful thread.</p>