[darcs-users] A couple of pre-newbie questions
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
- 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