Target Directory

[dbashford]

Target Directory

[dbashford]

The module just wraps git clone, and git clone has no means to do that. But I can fiddle with the file system and make that happen.

[dbashford]

This should be fixed now. But as is often the case, Windows...

There's also a good chance that the fix for this addressed issues #2 and issue #3, which I suspect are related.

Published 0.2.0 to npm of mimosa-skeleton.

[dbashford]

Had a chance to give this a go? Hoping all the problems were resolved with this. At least those you reported. =)

[EisenbergEffect]

Not yet. I've been swamped beyond believe. I'll try it out this afternoon.

On Tue, Jan 29, 2013 at 9:52 AM, dbashford [email protected] wrote:

Had a chance to give this a go? Hoping all the problems were resolved with
this. At least those you reported. =)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-12837998.

Rob Eisenberg,
Blue Spire Consulting, Inc.
Caliburn Project
850.264.3996

[EisenbergEffect]

Here's what I'm getting now:

C:\Projects> mimosa skel:new durandal test
15:33:21 - Retrieving registry...
15:33:22 - Found skeleton in registry
15:33:22 - Cloning GitHub repo [[ git://github.com/BlueSpire/Durandal-Mimosa-Skeleton.git ]] to temp holding directory.
15:33:23 - Moving cloned repo to [[ C:\Projects\test ]].
15:33:24 - Cleaning up...

fs.js:582
return binding.unlink(pathModule._makeLong(path));
^
Error: EPERM, operation not permitted 'C:\Projects\temp-mimosa-skeleton-holding-directory.git\objects\pack\pack-954af9c
e1d697356484c2e17a56d277bfaa2a439.idx'
at Object.fs.unlinkSync (fs.js:582:18)
at Object.exports.rmdirSyncRecursive (C:\Users\Rob\AppData\Roaming\npm\node_modules\mimosa\node_modules\wrench\lib\w
rench.js:150:16)
at Object.exports.rmdirSyncRecursive (C:\Users\Rob\AppData\Roaming\npm\node_modules\mimosa\node_modules\wrench\lib\w
rench.js:144:21)
at Object.exports.rmdirSyncRecursive (C:\Users\Rob\AppData\Roaming\npm\node_modules\mimosa\node_modules\wrench\lib\w
rench.js:144:21)
at Object.exports.rmdirSyncRecursive (C:\Users\Rob\AppData\Roaming\npm\node_modules\mimosa\node_modules\wrench\lib\w
rench.js:144:21)
at _cloneGitHub (C:\Users\Rob\AppData\Roaming\npm\node_modules\mimosa\node_modules\mimosa-skeleton\lib\command\new.c
offee:59:14)
at ChildProcess.exithandler (child_process.js:538:7)
at ChildProcess.EventEmitter.emit (events.js:99:17)
at maybeClose (child_process.js:638:16)
at Process._handle.onexit (child_process.js:680:5)

The test directory looks good. But the temp holding directory is still present.

[EisenbergEffect]

Same result if I don't include a target directory.

[dbashford]

Ugh, ok, well, closer is better. Looking further.

[dbashford]

0.3.0 pushed. Now using rimraf module to remove directory, which should alleviate any cross platform removal issues.

Give it a shot. You were failing on literally the last step, so hopefully this'll get us there. Let me know.

[EisenbergEffect]

Here's what I am getting now:

C:\Projects> cd test
C:\Projects\test> dir
C:\Projects\test> mimosa skel:new durandal
12:10:25 - Retrieving registry...
12:10:25 - Found skeleton in registry
12:10:25 - Cloning GitHub repo [[ git://github.com/BlueSpire/Durandal-Mimosa-Skeleton.git ]] to temp holding directory.
12:10:28 - Moving cloned repo to [[ C:\Projects\test ]].
12:10:28 - Cleaning up...
12:10:28 - An error occurred cleaning up the temporary holding directory Error: UNKNOWN, rmdir 'C:\Projects\test\temp-mi
mosa-skeleton-holding-directory.git\objects\pack\pack-954af9ce1d697356484c2e17a56d277bfaa2a439.idx'

The holding directory is actually empty, with the exception of the .git folder.

[dbashford]

First off, thanks for being my windows QA team.

I didn't think it was possible to get closer without being done.

But Error UNKNOWN is a bit of a problem. It doesn't help me too much. Is that path even a directory?

Are you able to successfully remove the .git directory? And if so, how would you do it? I may just have to, in the event of that error, and the fact that its dealing with windows, shell out and just exec something on the command line.

[dbashford]

As the original issue brought up in this ticket seems to be solved, I'm closing this out. I've opened a new issue regarding the problem with the .git folder on Windows.