[darcs-users] [patch251] resolve issue1268: enable to write darcs init x
guillaumh at gmail.com
Mon Jun 7 22:23:21 UTC 2010
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.
$ tree -L 2 temp_a/
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
>> 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
> 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
More information about the darcs-users