[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-users
Subject:    [darcs-users] Re: Retrieving a specific "version" of a file
From:       Kannan Goundan <cakoose () yahoo ! com>
Date:       2005-04-07 18:10:39
Message-ID: 20050407181040.99129.qmail () web51004 ! mail ! yahoo ! com
[Download RAW message or body]

David Roundy wrote:
> > Juliusz Chroboczek wrote:
> > >>     cp file file.copy; 
> > >>     darcs diff --to-patch=foo file | patch -R file.copy
> > >
> > > Yes, that's the way vc-darcs.el works (in the case when it
> > > cannot go under _darcs/current).  It's grossly inefficient, 
> > > though -- the first thing |darcs diff| does is to create 
> > > complete trees of both the
> > > from and to versions.
> > 
> > Is that required in the darcs model, or is it optimizable?
> 
> It is optimizable... and I seem to recall that some work has
> already gone into optimizing it.  But doing this *really* 
> efficiently will require storing per-file change information cached

> in some way.

I think that |darcs diff| without any options will be fast, because
all it does is make copies of the relevant files (in this case, only
one).

I think that it's the "--to-patch" part that's slowing things down
here (since Darcs has to do some patch-related stuff to create one of
the trees).  The recent |darcs diff| optimization only works when
making copies of the CURRENT or WORKING trees.

On the subject of a per-file cache...isn't this inevitable?  There
was this long thread where Andrea Arcangeli was arguing that the CVS
format made many operations much faster.  Of course Darcs can't use
such a format exclusively, but some appropriately designed format (a
file-to-patch mapping, in addition to the current patch-to-file
mapping) seems like it would make many of the performance problems
easier to solve.

- Kannan

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


[prev in list] [next in list] [prev in thread] [next in thread]