Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Destination path '.' already exists and is not an empty directory." message #97

Open
rochejul opened this issue Dec 17, 2014 · 3 comments

Comments

@rochejul
Copy link

Hi,

I would like to know more about the process of our bower registry.

I used an Ubuntu server, install Node/NPM, Git SVN and download your NPM. Then, I set the config JSON file similary to your example, with Git cache enabled.

I run the command, all seems fine.
I run an "bower install" on a remote desktop, the depencies are cloned and put into the repository JSON file. And I retrieve on my remote desktop the expected dependecies

BUT when I remove on my remote desktop the bower components and make an "obwer cache clean", and then a "bower install", I've got the following error on my server:

private-bower error fatal: destination path '.' already exists and is not an empty directory.

This error seems to occur when "private-bower" try to clone again the repository. The dependecies are still downloaded on the remote desktop.

So my question are:

  • This is a normal case ?
  • What is happening on the server ? It will try to update the cloned git repository ? Or this is a snapshot only for the first time ?
  • Can we force to refresh the git cache (by fetching, remove and clone again ) ?

Many thanks for your feedbacks

Cheers

Julien Roche

@Xiot
Copy link

Xiot commented Dec 20, 2014

I ran into this as well.
I threw in some debugging, and it looks like bower is hitting the /packages/:name route twice.

I was thinking that this case should be guarded against and if a second call comes in while we are in the process of fetching the repo, it should have to wait until the first request is complete. Pretty much through a mutex up around it.

I'll play with it this weekend and throw up a pull

@Xiot
Copy link

Xiot commented Dec 23, 2014

I managed to get this working on a basic level by putting a mutex up around the /packages/:name route to ensure that it is only trying to clone the repo once. I'm almost thinking of abandoning the git cache in my case as I am hitting #54 on my laptop. The original calls from bower are also timing out as the clone of some of these repos can take a while.
I'll try a bit more to see what I can get working.

@rochejul
Copy link
Author

Hi,

Thank you for your analyze !

I thnik I will first disable the Git cache and look for a solution later (git mirroring ? git pull ? ...)

Happy new year !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants