[darcs-users] Maintaining a history of compilable repository states

Henning Thielemann lemming at henning-thielemann.de
Sun Jan 17 16:53:15 UTC 2016


I am sure you darcs developers already thought intensively about the 
following problem, but I could not find a proposal or future plan page in 
the darcs wiki. Maybe this is the closest:
   http://darcs.net/Ideas/ShortSecureId

The great feature of darcs is that I can push and pull single patches 
around, i.e. cherry-picking is the default behaviour. The downside is that 
I can pretty easily create repository states that cannot be compiled or 
run. E.g. if I develop two features, each in a separate branch and then 
merge them, the conflicting parts will be removed from the repository and 
'darcs test' (usually a 'cabal configure && cabal build && cabal test') 
will fail. Even if there are no conflicts in the text, the merged patches 
may not form a compilable package. Additionally I am hardly able to get 
the two lines of development separated later.

Older darcs versions (e.g. darcs-2.5) had the 'trackdown' function.
   http://darcs.net/manual/Darcs_commands.html#SECTION006112000000000000000

It seems to be removed in darcs-2.10. I wonder how it can work if many 
interim states do not compile.

In Git this is no problem since it only stores snapshots (=commits) and 
every merge creates a new commit that you can inspect and improve and 
test. (Having said that, Git makes it pretty complicated to run a test 
that actually tests the current repository state.) The downside is that it 
cannot store file moves and token replacements.

What ideas or proposals do you have for reconstructing historic repository 
states and make 'trackdown' actually work? Maybe it would help to somehow 
mark patch sets that once in time succeeded to run a 'darcs test'. I 
should also be able to mark patch sets manually in case I cannot run a 
test temporarily (changes in versions of dependent libraries and 
compilers).


More information about the darcs-users mailing list