← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/darcs.txt

  • Committer: Martin Pool
  • Date: 2009-06-19 06:21:13 UTC
  • mto: This revision was merged to the branch mainline in revision 4558.
  • Revision ID: mbp@sourcefrog.net-20090619062113-019bp0a3bl2y4nkx
Un-soft-deprecate _supports_progress - still useful

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/darcs.txt
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
 
 
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
 
 
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.
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
 
 
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.
 
 
b'\\ No newline at end of file'