gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Google Summer of Code


From: John Arbash Meinel
Subject: Re: [Gnu-arch-users] Google Summer of Code
Date: Wed, 19 Apr 2006 21:32:46 -0500
User-agent: Mail/News 1.5 (X11/20060309)

Jeremy Shaw wrote:
> At Wed, 19 Apr 2006 18:31:25 -0400,
> James Blackwell wrote:
> 
>> Whats needed in this field is research on how to minimise the requirement
>> for history and then to delay downloading it until its necessary. There's
>> some anecdotal proof in the arch world that one can delay getting
>> information in ancestors until you actually need it.
> 
> darcs get has a --partial flag:
> 
>       --partial   get partial repository using checkpoint
> 
> You can create a check point with the 'darcs tag --checkpoint' (and
> possibly also 'darcs optimize --checkpoint')
> 
>      --checkpoint The --checkpoint option allows the tag be used later
>                   with the --partial flag to get or check.  A partial
>                   repository only contains patches from after the
>                   checkpoint. A partial repository works just like a
>                   normal repository, but any command that needs to
>                   look at the contents of a missing patch will
>                   complain and abort.
> 
> If you do a 'darcs get --partial', you can still record (aka, commit)
> new patches without downloading the full history.
> 
> Obviously, there is a lot more that could be done to automate it --
> but it is a neat start.
> 
> j.
> 

Can it annotate files if you have a --partial? And how well does it
handle merging under those conditions? I know it has complex patch
theory, so I'm just wondering what happens if you try to merge a tree
which has the common ancestor before the horizon.

It is actually pretty easy to allow people to commit with very limited
history. The only thing you really need is the immediate ancestor.
(Hence why Arch can do it with just a tag and a cacherev, or even just a
revision library).

The hard part is all the *other* stuff that you want to do, other than
just commit a change. But that might be a good start for the workflow
James is talking about. (A part-time committer doesn't usually do a lot
of fancy stuff).

John
=:->


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]