[darcs-users] A couple of pre-newbie questions

Albert Reiner areiner at tph.tuwien.ac.at
Fri Mar 4 13:55:23 UTC 2005


I have been using GNU Arch (Tla) for a couple of months, and it has
left me definitely unsatisfied.  Enough to contemplate switching to
Darcs which I find attractive for its conceptual simplicity and also
for its use of Haskell that I happen to know and like (which is not
true for the C languages).

Before I take the plunge, however, there are a couple of questions I
am not quite sure about after reading the manual.  In case it matters,
I am on Linux only, and I do not care in the least for anything else;
and I am the only developer, and most likely nobody else will ever
need to get anything from my repos.

- Symlinks: Is it correct that darcs does not know how to handle
  symbolic links at all?  What will it do when I try to add a symlink
  - just add the referenced file instead, or does it refuse to do
  anything at all, or will it silently do the Wrong Thing and run into
  problems later?  In an earlier thread on this list I read about
  someone working around this limitation by putting a script into the
  repository that sets up the necessary symlinks, which is likely to
  be workable.

- How to deal with conflicts: This one is absolutely unclear to me:
  say I have two patches that both want to modify the same line (and
  are not token replacements).  What is the result of pulling both?
  How do I know there is a problem?  How can I treat that conflict and
  record the resolution?  Do I need some external tool for that?

- Combining patches: Is there some way of creating one big composite
  patch from many small ones?  E.g., while trying to work out
  something I might make many individual changes, recording them as I
  go along, rolling them back when I note that they don't work, etc.;
  in the end when I have something that works, however, I would not
  want to conserve all those intermediate stages and the full history
  of my search but rather only record their combination.

  One way of doing this that might work somewhat is by getting some
  base version, pulling all the little patches, unpulling them again
  (or whatever command leaves the working tree intact), and recording
  a single patch.  OTOH, that should loose any work I may already have
  invested while recording the multitude of small patches, and things
  like token replacements or file operations will need special

- Naming conventions / boring: Is it correct that the only naming
  convention in darcs is what is considered "boring", and that this
  only affects the use of --look-for-adds?  Is that boringness
  enforced in any way, or can I still add a file that looks boring?
  Can I ever get into the situation where darcs classifies some file
  in a way that prevents me from recording (such as TLA does when it
  finds "U"nrecognized files)?

- White space in token replace: Is it still true that tokens cannot
  have whitespace in token replace?  This would actually be pretty bad
  for me: I do most of my programming with the noweb literate
  programming tool, <http://www.eecs.harvard.edu/~nr/noweb/>, and I
  routinely have chunk names like <<what to do next>> that are to be
  treated like tokens and that I might want to rename into something
  like <<the next step>>.  Or would it be possible to use rather
  general regexps matching anything starting with `<<' and ending with
  the next `>>', all on one line?

- Repo size: For strange reasons I have to carry anything I want to
  work on by floppies between my work computer and the one at home,
  and that is not going to change in the foreseeable future.
  Consequently, the size of a checked out repository is an important
  consideration for me: Does that mean that I should checkpoint often,
  use partial repositories most of the time, and avoid pristine trees?

- Supplementary files: On a related note, quite often I have a lot of
  things that I want to keep around but are not directly related to
  the core of the program that is to be version controlled: e.g., I
  might keep around a copy of some thesis or papers that are
  particularly relevant, or I might want to keep a record of some
  important debugging work, etc.; it is clear that those should go
  into the ``master'' repository where everything should end up.  But
  at the same time, for simply working on some problem I do not need
  any of that stuff, or only selected stuff that I can pull
  separately.  How does one handle that most easily?  One way would be
  to only get patches that don't match a certain pattern, but that
  makes every getting / pulling more tedious.  Would it be a
  reasonable idea to actually have several master repositories, where
  one would only hold the ``productive'' stuff and the others hold the
  supplementary files?  How do people handle that kind of situation?

- Can I just keep the individual patches around, without creating a
  pristine and working tree?  The idea here is related to the previous
  item: I might have modified some code for debugging and testing, and
  I might want to keep those modifications in a form where I can
  readily pull them in order to re-create those tests.  But different
  tests might conflict, and as they are not to be used together I have
  no reason to resolve those conflicts, which seems to indicate that I
  would have to keep around a full repository per test, or to litter
  that repository with one rollback patch per test patch.  Instead it
  would be easier to have a simple collection of ``inert'' patches
  that can be pulled at any time but that may be kept together without
  being applied to a useless pristine tree.  How do you handle that
  kind of thing with Darcs?

- Characters: I vaguely recall that Tla used to have a problem with
  `strange' filenames including, e.g., whitespace or non-ASCII
  characters.  Does darcs have similar problems?  What about non-ASCII
  text in files, patch names, regular expressions - will that cause
  problems (e.g. by making the file ``binary'')?

As you can see, many questions.

Thanks in advance,


More information about the darcs-users mailing list