Clonning only from version and diff before pulls

Kevin Smith yarcs at qualitycode.com
Wed Aug 17 15:01:19 CDT 2005


Andrew Thompson wrote:
> Quoting Daniel Santa Cruz <byteshack at gmail.com>:
> 
> One of the features of Hg is cloning by hardlinking. If your upstream is 
> on the
> same filesystem as your working copy, you only use space for your actual
> current working copy, and the .hg/ files that have been changed by local
> commits.

*And* if your operating system and file system support hardlinking. For 
MS Windows developers, that's rarely true. The whole paradigm of 
mercurial (and other repo-inside-working-tree SCM tools) is that clones 
are cheap. When they are not, the tool becomes less effective. This has 
become a significant concern to me, because my MS Windows-using 
teammates will resist tools that make them second-class citizens.

Would there be any way at some point to have some kind of "patch pool" 
in mercurial? Something similar to an ArX (and presumably GNU arch) 
archive, or a GIT alternate directory? Based on my terrible 
understanding of the hg repo format, I'm guessing it would be difficult 
if not impossible. But I would love to hear otherwise, even if it's only 
theoretical.

>> I keep "sandox" sync'ed with "upstream" by periodically making sure
>> that I'm not straying too far away from it.  Is there a way for me to
>> see what I would be pulling (doing a diff) before I actually do the
>> pull?  This would allow me some control over what gets put into my
>> "sanbox" repository.

You seem to be operating with an eternal sandbox. Would it be possible 
for you to shift to a mode where every time you began work, you would 
clone a fresh copy of upstream as your new sandbox? The case where this 
wouldn't work is if you have patches that have not yet been accepted 
upstream. That case seems to be exactly the target of the MQ extension, 
although I haven't actually worked with it yet.

You could also clone your upstream into old-upstream right before doing 
a pull into upstream. Then you could diff the old-upstream and upstream 
trees to see what was new.

Kevin


More information about the Mercurial mailing list