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).
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
