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