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

Albert Reiner areiner at tph.tuwien.ac.at
Sat Mar 5 21:00:51 UTC 2005

Thanks for the answers!

[Mark Stosberg <mark at summersault.com>, Sat, 5 Mar 2005 02:53:01 +0000 (UTC)]:
> On 2005-03-04, Albert Reiner <areiner at tph.tuwien.ac.at> wrote:
> Welcome. I hope you enjoy darcs. 

I definitely hope so, too!

> >   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)?
> You can find dicussion in the past where darcs throught my file was
> binary and I didn't want it to be. In the end, there were some fairly 
> simple solutions there.

Thanks, I found the thread "more feedback on binary file detection"
from December 2004.  If I understand correctly,

- the solution is to make sure there are no ^@ or ^Z characters in the
  file, and

- darcs did not simply refuse to record something but merely didn't
  recognize it as text.

> I'll have to let someone else answer that. In my experiments with token
> replace it  never worked as I expected, and I used find and
> replace instead, which worked fine. 

I see; what are the problems?  Some googling found:

- conflicts are not marked for conflicting involving token
  replacements (still true?)

- replacements persist even when pulling from another repository,
  which is actually the main feature for those patches but may be

Anything else?

Actually I start being ever more confused in this matter: How does a
token replacement patch ``know'' to what text it applies and to which
it doesn't?  Suppose Alice and Bob are working on a joint project.
They both start out with some common base version, |0>; in that base
version, foo is used as a variable name.

- Alice decides that bar is much more expressive and records a token
  replacement foo -> bar.

- In the meantime Bob records a patch B that adds the statement "I
  like foo" to the preferences file.

- Alice pulls B; clearly, this should result in a preferences file
  with "I like bar" in it.

- Now Alice adds "And I hate foo" to the preferences file, and this
  must not be changed to "And I hate bar", presumably because it comes
  after the foo -> bar patch.

- Now Bob records a patch B' that adds the statement "Some people like
  foo" to the preferences file.

- Now what happens when

  - Bob pulls the foo -> bar patch from Alice?

  - Alice pulls B'?

  My guess is that both now have a preferences file with the statement
  "Some people like bar" in it.  For this, it seems, darcs would have
  to know not only about the patch it is pulling but also about
  whether or not the foo -> bar patch was present at the time when the
  various patches were recorded.

  Which seems to imply that anything done after the replacement foo ->
  bar and involving bar would have to depend directly or indirectly
  upon that foo -> bar patch, and the foo -> bar patch would have to
  conflict with any patch using foo that does not depend on the foo ->
  bar patch.

  Which again seems to imply that a situation where Alice and Bob both
  decide to use bar instead of foo and record separate foo -> bar
  patches is a very different thing from one where only one makes that
  replacement and the other one pulls it:

  - Alice and Bob start from a common set of patches.

  - Alice records foo -> bar

  - Bob records foo -> bar

  - Alice does and records some work, some of which has to do with

  - Bob adds "foo is bad" to preferences, records B''

  - Alice pulls B'' and gets "foo is bad", but this goes by commuting
    B'' with Bob's foo -> bar (which gives
    (Bob:foo->bar).B''.(Bob:bar->foo)), commuting that with
    (Alice:foo->bar) (which gives
    and from then on over any work done by Alice until it is the last

    If there had been only a single foo->bar patch, then  
    could just be replaced by B''.

    Two questions:

    - Do I have that approximately right?

    - More generally, do multiple patches that ``do the same thing''
      cause problems?

Thanks in advance for any clarifications,


More information about the darcs-users mailing list