|
6
by mbp at sourcefrog
import all docs from arch |
1 |
Darcs compared to Arch |
2 |
====================== |
|
3 |
||
4 |
Simpler to use; perhaps harder to completely understand. |
|
5 |
||
6 |
Always local; always fast. |
|
7 |
||
8 |
Patch commution is slow and perhaps doesn't clearly do what people |
|
9 |
want. |
|
10 |
||
11 |
Too slow! |
|
12 |
||
13 |
Can't reliably get back to any previous point. Explicitly not |
|
14 |
addressing source archive/librarian function. |
|
15 |
||
16 |
Loads everything into memory. |
|
17 |
||
18 |
Written in Haskell. |
|
19 |
||
20 |
A really simple pre-commit check hook is remarkably useful. |
|
21 |
||
22 |
http://www.scannedinavian.org/DarcsWiki/DifferencesFromArch |
|
23 |
||
|
47
by mbp at sourcefrog
notes on more good bits from darcs: partial commit, etc |
24 |
|
25 |
||
26 |
Sometimes useful to be able to set email per-branch, for people who |
|
27 |
work on different projects under different personas. |
|
28 |
||
29 |
||
|
6
by mbp at sourcefrog
import all docs from arch |
30 |
Token replace |
31 |
------------- |
|
32 |
||
33 |
Very cute; possibly handy; not absolutely necessary in most places. |
|
34 |
Somewhat limited by the requirement that it be reversible. |
|
35 |
||
36 |
This is one of very few cases where it does seem necessary that we |
|
37 |
store deltas, rather than tree states. But that seems to cause other |
|
38 |
problems in terms of being able to reliably sign revisions. |
|
39 |
||
40 |
This can perhaps be inferred by a smart 3-way merge tool. Certainly |
|
41 |
you could have it do sub-line merges. |
|
|
47
by mbp at sourcefrog
notes on more good bits from darcs: partial commit, etc |
42 |
|
43 |
Partial commit |
|
44 |
-------------- |
|
45 |
||
46 |
darcs allows you to commit only some of the changes to a single file. |
|
47 |
This is like the common feature of commiting only a subset of changed |
|
48 |
files, but taken to a higher level. |
|
49 |
||
50 |
It is useful more often than one might think: it is common to fix some |
|
51 |
documentation 'on the wing' and while strictly it should be in a |
|
52 |
separate commit it is not always worth the hassle to back out changes, |
|
53 |
fix the docs, then do the real change. Similarly for making a |
|
54 |
separate branch. |
|
55 |
||
56 |
Although the idea is very good, the current darcs implementation is |
|
57 |
limited to selecting by patch hunk, which means that neighbouring |
|
58 |
changes cannot be separated. Fixing this probably means having some |
|
59 |
kind of pluggable GUI to build the file-to-be-committed or an edited |
|
60 |
patch, possibly using something like meld, emacs, or dirdiff. Another |
|
61 |
approach some people might like is editing the diff file to chop out |
|
62 |
hunks. |
|
63 |
||
64 |
I don't think this needs to be on by default, as it is in darcs. It |
|
65 |
is usual to commit all the changes. |
|
66 |
||
67 |
For this to work safely, it is good to have a commit hook that |
|
68 |
builds/tests the tree. Of course this needs to be evaluated against |
|
69 |
the tree as it will be committed (taking account of partial commits), |
|
70 |
not the working tree. |
|
71 |
||
|
75
by mbp at sourcefrog
more notes on darcs |
72 |
|
73 |
Schwern |
|
74 |
------- |
|
75 |
||
76 |
* http://www.scannedinavian.org/DarcsWiki/SchwernLikesDarcs |
|
77 |
* http://www.scannedinavian.org/DarcsWiki/SchwernHatesDarcs |
|
78 |
||
79 |
I think we hit most of these; more evidence for the hypothesis that |
|
80 |
what people really like about darcs is the simple interface not the |
|
81 |
patch-commutation model. |