Sparse working copy

[Boggess, Rod]

Hg doesn't support checkin-checkout, but I'm guessing you knew that. Would  
an archive suit your needs? You could archive without the repo, then just  
copy files changed atop files in your full repo to do commits from there. 

Sent from my Motorola Smartphone on the Now Network from Sprint!

-----Original message-----
From: Jan Vrany <jan.vrany at fit.cvut.cz>
To: mercurial at selenic.com
Sent: Fri, Nov 16, 2012 06:43:15 EST
Subject: Sparse working copy

Hi there,

I'm now implementing Mercurial support for Smalltalk/X environment.
The goal is to replace currently used CVS and SVN (both are used).
I have to say that I'm mercurial newbie, but so far I quite like it.
However, there are some issues because our workflow, which is rather
specific and unusual.

I would need a "sparse" working copy, a handy feature of SVN. That means, a  
possibility to clone a repository and have only a part of the of the files  
checked out in the working copy (only subdirectory of whole tree and and not  
in full depth). I mean, lets say full structure is:
  p1
   - c1.st
   - c2.st
   - makefile
   - plugin1
     - data1
   - plugin2
     - data2

To modify c1.st, i need to clone the repository sparsely, so
the working copy contains only c1.st, c2.st, makefile and possibly
empty plugin1 & plugin2. I do not need to have data1 and data2 in my
WC for they are HUGE (1GB, say) and I certainly won't touch them
from IDE.

I guess this is not currently possible, is it? Would it be possible
to achieve this by an extension? My idea is to add another state to
dirstate - 's' -- sparsely checked out and when doing a status & commit
treat missing files marked as 's' in dirstate as clean.
Any hints, suggestions how hard this would be to implement?
Is is possible to do it as third-party extension without modifying
core hg classes?

Best, Jan

P.S.: For those asking "Why on hell would anybody need that?" :-)

Let me explain the workflow first

1) you clone/checkout repository from server to filesystem
2) compile sources
3) start the IDE. Develop (add/remove/change methods). This changes
    DOES NOT modify any files, all is done in memory. New source of
    method is kept in memory, source old methods (which have been
    compiled in step 2) is NOT in memory, only offsets into corresponding
    source files is kept so save memory.
4) If you commit, a source is *reconstructed* by sequentially
    writing out sources of
    individual methods. If it hasn't been changed, original source
    file is consulted. Therefore, if anybody ever modifies the
    original source file on the disk, offsets to source files
    become invalid and everything is messed up.
    Therefore you have to save sources to a temporary working copy
    and commit from there.
5) possibly go to 3)
6) quit ide, update working copy created in step 1)
7) goto 2)


So now, when doing a commit, now I make a temporary clone of the repository
from 1), write sources there, do a commit and immediately push back to
the upstream repository (the one created in step 1). Cloning into this  
temporary repository is a problem, not because of a history
(hardlinks work fine), but because of the working copy could be huge.

And no, we cannot change either the workflow nor out directory layout.
No way, sorry.
_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20121116/3ba0de2b/attachment-0002.html>