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/
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.
guillaume
ps: this reminds me of a discussion on this list about darcs put
needing to go away.
http://www.mail-archive.com/darcs-users@darcs.net/msg08704.html
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:
http://www.codysoyland.com/2010/jun/6/ssh-tip-automatic-reverse-tunnels-workflow-simplif/
?
See the comment :
http://www.codysoyland.com/2010/jun/6/ssh-tip-automatic-reverse-tunnels-workflow-simplif/#comment-55054902
(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.dor...@gmail.com> wrote:
> Hello Guilllaume,
>
> On Mon, May 31, 2010 at 1:12 PM, Eric Kow <ko...@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
>
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
