~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/darcs.txt

• browse files at revision 1185.1.48
• compare with another revision
• download diff
• download tarball
• view history from revision 1185.1.48

• reverse the comparison (1185.1.48 to 5452)
• stop comparing with revision 5452

Show diffs side-by-side

added

removed

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'

• Older »

Loggerhead is a web-based interface for Breezy
Version: 2.0.1