What should I do with the vendor directory with respect to subversion?
-
02-07-2019 - |
Question
So I have a problem. I checked in my frozen gems and rails even though you aren't supposed to do that. I figured it was easy and wouldn't be that big of a deal anyway. Well, later I updated rails and in doing so deleted all the .svn files in the vendor/rails directories. I have heard that what I really should do is just do something to do with svn:externals to my vendor directory. What exactly do I need to do and will capistrano still use my frozen gems if they aren't in my repo? If it will not use my frozen gems how can I regenerate those .svn files correctly, because this will happen again.
Thanks!
Solution
To recover your deleted
.svn
directories, just run ansvn update
. They'll come back.I just check in exported gems. I use
gem unpack <gemname>
in thevendor/gems
directory andsvn add
andcommit
from there.Anything in
vendor/plugins
orvendor/rails
I track using piston. For example, this is how I get rails in there:% piston import http://dev.rubyonrails.org/svn/rails/tags/rel_2-0-2/ vendor/rails
To get piston use gem install piston
.
Note I'm going to have to find a different/better solution to replace piston as Rails continues to use git and may not update the subversion repository.
OTHER TIPS
Personally, I'm partial to using Piston to manage the vendor directory.
I'd have to advise against svn:externals for two reasons
you might be deploying into an environment that cannot reach those svn services
what happens when you want to deploy and those svn external are down?
My advice is to use piston or gem unpack and manage your production dependancies in your vendor tree.
Disclaimer: I don't know Ruby/Rails, so I don't know what frozen gems are (though I assume they're compiled binaries or tokenized source), but I know Subversion well.
.svn directories only hold Subversion "bookkeeping". There's nothing in there that's unrecoverable.
Deleting your .svn files is not a problem at all. If the directories with the missing .svn directories are somewhere inside a tree of directories in your subversion working copy (the directory you did a checkout into), just delete those directories, do an svn update, and they will be recreated.
If the whole tree is missing the .svn files, delete the whole tree and do a svn checkout again.
svn:externals is like a "symbolic link". You have Project A and Project B, which uses Project A. What you do is add an svn:external property that references the library directory of Project A, so whenever you check out Project B, it will automatically put the library directory from Project A in it. For instance, I often have a directory called "thirdparty" which holds the externals to libraries from elsewhere, including evn:external references to other projects in subversion.
One tip for solving version problems like this is to have separate release directories for the libraries (or frozen gems), and in your projects that need them, use an svn:external reference to the appropriate release directory. As new releases come out, just change the svn:external property to point at the new release directory and svn update.