Подтвердить что ты не робот

Очистка старых ссылок в Ruby Version Manager (RVM)

Мне нужно освободить дисковое пространство на моей локальной машине, которая почти выделена в мой каталог Ruby Version Manager (RVM).

Теперь, кажется, у меня есть только одна рубиновая версия (1.9.2p136):

[email protected]:~/rails/github/gitwatcher$ ruby -v
ruby 1.9.2p136 (2010-12-25 revision 30365) [i686-linux]
[email protected]:~/rails/github/gitwatcher$ 

[email protected]:~/rails/github/gitwatcher$ rvm list
rvm rubies
=> ruby-1.9.2-p136 [ i386 ] 
[email protected]:~/rails/github/gitwatcher$

[email protected]:~/rails/github/gitwatcher$ which ruby
/home/lsoave/.rvm/rubies/ruby-1.9.2-p136/bin/ruby
[email protected]:~/rails/github/gitwatcher$ 

но мой RVM-каталог, есть много других несвязанных dirs/версий:

[email protected]:~/rails/github/gitwatcher$ ls -la ~/.rvm/gems
total 72
drwxr-xr-x 18 lsoave lsoave 4096 2011-05-21 15:44 .
drwxr-xr-x 23 lsoave lsoave 4096 2011-02-10 22:46 ..
drwxr-xr-x  2 lsoave lsoave 4096 2010-08-29 19:50 cache
drwxr-xr-x  2 lsoave lsoave 4096 2010-08-31 21:50 jruby-1.3.7
drwxr-xr-x  2 lsoave lsoave 4096 2010-08-31 21:50 jruby-1.3.8
drwxr-xr-x  2 lsoave lsoave 4096 2011-05-21 15:44 ree-1.8.7-2010.02
drwxr-xr-x  8 lsoave lsoave 4096 2010-09-08 11:25 ruby-1.8.7-p302
drwxr-xr-x  7 lsoave lsoave 4096 2010-08-29 22:00 [email protected]
drwxr-xr-x  7 lsoave lsoave 4096 2010-08-29 22:24 ruby-1.9.2-head
drwxr-xr-x  7 lsoave lsoave 4096 2010-08-29 22:24 [email protected]
drwxr-xr-x  8 lsoave lsoave 4096 2010-08-31 23:47 ruby-1.9.2-p0
drwxr-xr-x  7 lsoave lsoave 4096 2010-08-29 19:50 [email protected]
drwxr-xr-x  8 lsoave lsoave 4096 2011-02-10 19:44 ruby-1.9.2-p136
drwxr-xr-x  7 lsoave lsoave 4096 2011-02-10 19:23 [email protected]
drwxr-xr-x  7 lsoave lsoave 4096 2011-04-08 21:21 [email protected]
drwxr-xr-x  7 lsoave lsoave 4096 2011-04-09 00:57 [email protected]
drwxr-xr-x  7 lsoave lsoave 4096 2011-02-15 00:09 [email protected]
drwxr-xr-x  2 lsoave lsoave 4096 2011-02-10 19:04 system
[email protected]:~/rails/github/gitwatcher$

Сохраняется ли удаление всех оставшихся серверов с рубинами "ruby-1.9.2-p136" и "[email protected]" ([email protected]* являются старыми и "Система rvm" ничего не возвращает "? Использую ли я команду" rm", или есть ли реализованные команды RVM для очистки лучшего пути? Возможно ли очистить кеш-память?

Спасибо заранее. Luca

4b9b3361

Ответ 1

Я полагаю, что rvm cleanup может сделать трюк.

Кроме этого, я не вижу причин, по которым удаляются фактические каталоги gem внутри RVM, если они больше не связаны с RVM.

Если соответствующая запись не существует в environments, тогда безопасно удалить сопровождающий gem dir. Поскольку ничто иное не указывает на то, что RVM сможет использовать.

Ответ 2

... получается, что некоторые из предыдущих, не используемых refs, были просто gemset:

rvm gemset list
[email protected]:~$ rvm gemset list

gemsets for ruby-1.9.2-p136 (found in /home/lsoave/.rvm/gems/ruby-1.9.2-p136)
global
greendog
greendog2
greendog99

[email protected]:~$

который я удалил следующим образом:

[email protected]:~$ rvm gemset delete greendog99
Are you SURE you wish to remove the entire gemset directory 'greendog99' (/home/lsoave/.rvm/gems/[email protected])?
(anything other than 'yes' will cancel) > yes
[email protected]:~$ rvm gemset delete greendog2
Are you SURE you wish to remove the entire gemset directory 'greendog2' (/home/lsoave/.rvm/gems/[email protected])?
(anything other than 'yes' will cancel) > yes
[email protected]:~$ rvm gemset delete greendog
Are you SURE you wish to remove the entire gemset directory 'greendog' (/home/lsoave/.rvm/gems/[email protected])?
(anything other than 'yes' will cancel) > yes
[email protected]:~$

чем я сделал резервную копию одной из старых "lib" (на всякий случай...):

[email protected]:~/.rvm/gems$ tar zcvf ruby-1.8.7-p302.gz ./ruby-1.8.7-p302

и удалил относительный каталог как предыдущий комментарий, с помощью stuartc:

[email protected]:~/.rvm/gems$ rm -rf ./ruby-1.8.7-p302

теперь вернемся к работе.

Я подожду пару дней, ища все правильно...