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

Tommy Pettersson ptp at lysator.liu.se
Sat Mar 5 07:35:00 UTC 2005


(I wrote some of this reply before Mark replied, so I might
be repeating some of his answers.)

On Fri, Mar 04, 2005 at 02:55:23PM +0100, Albert Reiner wrote:

> - Symlinks: Is it correct that darcs does not know how to handle
[...]

darcs will refuse to add a symbolic link foo with the cryptic
message "File foo does not exist!"


> - How to deal with conflicts: This one is absolutely unclear to me:
[...]

I will write something about this in the manual ... real soon
now...  I thing Mark gave a good explanation.
Here is some edited cut'n'pasteing from some mails I've
written before, that I'll paste all the way to the docs
(that was soon, wasn't it? ;-)


Conflicting patches are created when different changes
to the same line in the same file are recorded in two
different repositories.(footnote: not same line as in same
line number, but same as in from the same previous patch.)
A conflict happens when two conflicting patches meet in the
same repository.

This is no problem for darcs; it can happily pull together
just any patches.  But it is a problem for the working files
of the repository.  The conflict can be thought of as two
patches telling darcs different things about what a line
should look like.

When a conflict happens, darcs will insert both versions
of conflicting lines in the file, with conflict markers
around them.  To resolve the conflict, just edit the file
to what it really should look like and record.  The record
will result in a patch that tells darcs what these lines
should look like, regardless of what any previous patches
(conflicting or not) says.


> - Combining patches: Is there some way of creating one big composite
[...]

It is possible to unrecord a couple of patches and then record
the total change as a new patch.  Addfiles, token replaces and
other special patches will be preserved during this operation;
they will simply be moved from pristine to pending when they
are unrecorded, where they can be individually cherry-picked
for a new record that moves them back to pristine.  You have
to revert them to destroy them (and undo their changes to the
working dir).  Ordinary hunks (line adds/removes), however,
are calculated automatically at every record, and since
adjacent lines are always put in single hunks, adjacent or
overlapping hunks in unrecorded patches will "lump together"
and can only be recorded again as single hunks.  For the
purpose of joining patches, this will of course be desired.
In practice, dependencies between patches will sometimes
disable cherry-picked joints, but joining the last x patches
will always be possible.  A way to make sure no other patches
"get in the way" is to do develop them separately in a
temp repo.


> - Naming conventions / boring: Is it correct that the only naming
[...]

There is also a similar pref file called binaries, with
patterns for filenames to treat as binary.

Without option --boring (default): boring files can not be
added to darcs in any way.  With option --boring: boring
files can be added to darcs (in all ways).

I'm afraid I can't explain how binary files are handled.
I think there is some automagic with special chars in the
file involved.


> - White space in token replace: Is it still true that tokens cannot
[...]
>   for me: I do most of my programming with the noweb literate
[...]

And I thought I was the only one on earth who used noweb...  :-)

I can't remember if I've tried this before, but as soon as
I put a space in the token pattern, darcs generates hunks
instead of replace patches.  But even if it did work, all
<<chunks>> would have to be surrounded by non-token chars
(i.e., not spaces) for it to work.

Real regexps would be nice.  Even better would be something
like sam script hunks.  But I'm pretty sure that would violate
the  reversibility constraint on patches.

Anyway, some people will say replace hunks are no good.
I don't agree, but I'll attest you can go a long way with
darcs without them.


> - Repo size: For strange reasons I have to carry anything I want to
[...]

The patch files and the inventories are all that is needed to
"repair" a repo.  So far darcs doesn't ever delete patch files,
which means unrecorded and unpulled patches have their patch
files lingering about.  A get of a repo will however only
copy/link the patch files in use.

You could instead carry context files and patch files.
Before you leave home you 'darcs send' against the latest work
context file to a patch file and also generate (darcs changes
--context) a fresh home context file.  Bring those two files to
work.  At work you apply the patch file and continue working.
At closing time, 'darcs send' against the latest home context
file (you brought with you) to a new patch file and generate a
fresh work context file.  Bring them home and repeat the cycle.

I have a feeling that in this case the context file could
be extracted directly from the patch file and doesn't have
to be generated and carried alongside.  Does anyone know if
and how to do that?


> - Supplementary files: On a related note, quite often I have a lot of
[...]

This is a hard question.  There are many ways to use darcs,
and some of them have performance issues.

I think the easiest way is to keep multiple repos.  Patches can
be moved around between repos pretty freely as long as they
don't conflict (and you can wait while darcs is sorting them
out for you).  If you work in the some_work repo and find a
bug, you can pull in the bug tale files from the bug_tale repo,
and fix the bug and document the hunt in the some_work repo.
You can then push the new bug tale patches to the bug_tales
repo and the bugfix patches to the main_work repo.  Once the
patches are safely stored elsewhere, you can unpull the bug
tale patches in the some_work repo and continue with some
work that got interrupted by the bug.

If you want to collect all the repos in a temporary bring_along
repo, just tag each master_repo first, and then pull everything
together.  'darcs get --tag TAG' will then pick out just the
tagged patches and recreate the various master repos.

Multiple repos with subsets of patches of each other works
fine.

For my projects I keep many "additional" patches in a work
repo, that I don't pull to the release repo where I compile new
"real" versions.  In the release repo I update the version
number and create a tag.  I always pull these two patches
back to the work repo.

Once upon a time I did not pull them back.  I though it was
nice to always have version 0 in development compilations.
But I got to close to the version number line in the work
repo plus I had made a "fix" early in the release repo (that
was later duplicated in the work repo), and after a while it
started to cause conflicts that grew exponentially until I
couldn't pull/push any more.  It was no disaster; I had all
the patches and could construct a new release repo from the
work repo, with almost the same "versions".


> - Can I just keep the individual patches around, without creating a
>   pristine and working tree?  The idea here is related to the previous
[...]

I don't think it is possible to push with --no-resolve with
the latest darcs, which is a problem if you can't lose the
working tree.  The without pristine and working part I'll
pass on.


> - 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'')?

I can answer for non-ASCII in text files.  It works but the
non-ASCII is escaped when darcs prints it on the screen.
For single-byte encodings, darcs can be told to rely on
isprint() and the current locale by setting environment
DARCS_USE_ISPRINT=1.

> As you can see, many questions.

And good questions too.  I'll try to put some answers to them
in the manual.

-- 
Tommy Pettersson <ptp at lysator.liu.se>




More information about the darcs-users mailing list