[darcs-users] Darcs for GHC [was: darcs weekly news #28]

[Jason Dagit]

On Wed, May 13, 2009 at 2:20 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 13/05/09 04:54, Trent W. Buck wrote:
>
>> Eric Kow<kowey at darcs.net>  writes:
>>
>>> Nevertheless, if the GHC team are going to postpone their switch, what
>>> can we do to make their current darcs experience more enjoyable?
>>>
>>
>> Do we know how long GHC plan (either officially or unofficially) to
>> defer their VCS migration for?  It's all very well for us to talk about
>> a twelve-month roadmap for major improvements, but if GHC are really
>> looking at migrating in the next quarter, that's not going to help.
>>
>
> It's probably time we took another look at the options, that's all. Darcs
> still doesn't really support the development model we'd really like though
> (long-lived branches and lots of merging).  On the other hand, darcs is
> supporting our other workflows reasonably well - for example pulling fixes
> into the stable branch is usually nice and easy.


I'd like to learn more about this workflow.  I know the book, "Producing
Open Source Software" by Karl Fogle (an SVN developer), has commentary about
branches[1].  In particular, you don't usually want people to go off and
work on one thing in a branch and never merge because when they finally do
it will be painful.  I don't think this is what your suggesting though.  I
think you're suggesting that you have the branch where they go off and do a
lot of work, but they merge regularly to avoid the pain of infrequent
merges.  Is this what you're referring to?

Now, trying to understand why darcs doesn't meet your needs for this case.

Is it because of conflicts that seem to grow ever larger as you merge in the
future?  If so, I think there was a feature planned to help with this, but I
don't know where the status is at this time.  The command was going to be
called "transplant", if I recall correctly.  There were a few different
ideas about the semantics, and one such idea was to have it apply remote
patches without their dependencies by creating a new patch containing their
diff and applying it locally.  Is that roughly what you want?  A way to
migrate specific patches without pulling in their dependencies and hence
patches that create local conflicts?  It would make the branches
increasingly divergent in terms of patches but it would get them to a
similar state of files and contents.  I believe this functionality is
similar to at least one use of Git rebase.


> I want to try out hashed again.  Last time I tried it, there were
> performance problems, but it turned out that hashed repos were using a
> global cache by default, and my home dir is NFS-mounted.  There was a
> problem with turning off the global cache IIRC - has that been fixed now?
>  I'd really like to either disable the cache, or point it to somewhere
> locally mounted.


Checking the manual right now I see this[2]:

On MS Windows [image: [*]] <http://darcs.net/manual/node5.html#ms_win>,
using cmd.exe (Command Prompt under Accessories):

> md "%UserProfile%\Application Data\darcs\cache" (notice double quotes!)
> echo cache:%UserProfile%\Application Data\darcs\cache > "%UserProfile%\Application Data\darcs\sources"

It seems to be user configurable.  Perhaps you could set the cache to be in
a temp folder on your local drive.  Or even try a USB drive as your cache.
 I've found the cache to make a huge difference when frequently getting the
same repository.

Thanks,
Jason

[1] http://producingoss.com/en/vc.html
[2] http://darcs.net/manual/node6.html#SECTION00630000000000000000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090513/84bdaaeb/attachment.htm>