[darcs-users] [patch251] resolve issue1268: enable to write darcs init x

Guillaume Hoffmann guillaumh at gmail.com
Mon Jun 7 22:23:21 UTC 2010

Hi Rado,

thanks for your review. I've looked at your patch and the failing test.
Your patch does not have any problem with --darcs-2, but with the put command.

If you do the following with your patch:

$ ./darcs init temp1
$ touch temp1/a
$ ./darcs add temp1/a --repodir=temp1
$ ./darcs rec -am 0 --repodir=temp1
$ ./darcs put --repodir  temp1 temp_a

You get for the last line:

darcs failed:  Unable to "darcs apply" here.

You need to be in a repository directory to run this command.
Apply failed!

What happened:

$ tree -L 2 temp_a/
└── temp1
    └── _darcs

Internally, "darcs put" calls "darcs init", and the trouble belongs is
linked to this call because somehow, at that point "darcs init"
receives this --repodir=temp1 argument (under the form of WorkRepoDir
"temp1/"), and this argument gets passed to the call to "darcs init"
while the pwd is temp_a.

I don't understand why such a problem does not happen without your patch!

The functions amNotInRepository and amInRepository (respectively used
in Init and Put) create a change of pwd that may cause this problem.


ps: this reminds me of a discussion on this list about darcs put
needing to go away.


The problem above would not happen if a local  "darcs put" would
translate as a "darcs get". As for remote "darcs put", would it be
possible to still call "darcs get" by using such a trick:
See the comment :

(Maybe this deserves a separate mail thread, if you want to react to this)

On Thu, Jun 3, 2010 at 12:25 AM, Radoslav Dorcik
<radoslav.dorcik at gmail.com> wrote:
> Hello Guilllaume,
> On Mon, May 31, 2010 at 1:12 PM, Eric Kow <kowey at darcs.net> wrote:
>> I believe here we've got a confrontation between two principles:
>> - the less invasive a change the better
>> - the more uniform/coherent/consistent the code the better
>> Looking through the code, it seems that right now, all the commands
>> check their prereqs with the commandPrereq function (and this includes
>> things such as the context file existing).  There are some lightweight
>> prereqs for darcs get that don't seem to get checked (for example, that
>> if you say darcs get foo bar), but it seems like that could easily
>> change.
>> So what should we do here?  Maybe it would be good if you and Guillaume
>> could work together to figure out why your (Rado)'s draft fails the test
>> currently.  Also one thing to think about: how are prereqs currently
>> handled and should it be improved?
> only quick cross-check of my understanding of your patch:
> - the Init.hs has been changed since it contains implementation of the
> "darcs init" command
> - commanding related code has been changed due new parameter in prereq [String]
> - the amNotInRepository uses additional argument for setting working repo
> - the amInRepository and all other change funnctions (e.g. findRepo)
> doesn't use additional parameter ([String])
> Am I right ?
> It looks like that my patch (less invasive, but not very nice) somehow
> causes "ignoring" --darcs-2 parameter for "darcs init" command in the
> tests.
> It is necessary discover which code is resposible to take into account
> this --darcs-2 flag and what does it mean (since it looks to be
> default).
> Thanks,
> Rado

More information about the darcs-users mailing list