Sparse working copy

Jan Vrany jan.vrany at fit.cvut.cz
Sat Nov 17 10:47:26 UTC 2012


On 17/11/12 00:52, Boggess, Rod wrote:
> Hg doesn't support checkin-checkout, but I'm guessing you knew that.

Yes, I know. Maybe not correct terminology, but you know what I mean.

> 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.

Unfortunately not easily. But maybe we will end up with implementing
that (there are lot of consequences on the Smalltalk side and would
require a lot of refactoring).

Jan

>
> /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
>




More information about the Mercurial mailing list