On 4/24/2011 1:35, Orchid XP v8 wrote:
> There really has to be a better way of solving this problem than serialising
> the entire change history forever...

Well, as I see it, both git and darcs stores a DAG. Git stores a DAG of 
collections-of-files, and Darcs stores a DAG of collections-of-changes. Git 
stores enough information that you can reproduce the changes from the files 
well after the fact. Darcs does not store enough information that you can 
reproduce files from changes reliably (in that I can't tell what files you 
were looking at when you made a particular change, for example).

So, basically, there are changes that have known dependencies, and changes 
that have unknown dependencies. Git records all history explicitly, 
including dependencies that may or may not actually exist. Darcs assumes if 
you don't tell it about the dependencies that they specifically don't exist. 
Darcs also fails to record anti-dependencies. Git lets you put multiple 
histories in the same repository, while Darcs can't really represent 
multiple histories so you wind up with lots of individual repositories to 
manage with apparently no good tools to compare them (since the DAG between 
different repositories is intentionally discarded when you clone the 
repository, as I understand it).

I think if you're working on a small project, either by yourself or with a 
small team you're in communication with on a frequent basis, either might 
work. Either seems pretty easy to understand.

The only way of improving on serializing the change history is to specify in 
Darcs exactly what you rely upon and what you don't, which would seem to 
require actually doing a full analysis of the program every time you check 
in a change. If function XXX relies on the behavior of function YYY, and you 
change function XXX and I change YYY, there may or may not be a dependency 
between those two changes, depending on whether I "break" your XXX with my 
change to YYY. But then you have to define "break".  I can see, however, how 
a language like Haskell or Eiffel or something with 100% test coverage 
available to every repository holding the project could make that mostly 
feasible.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message