[Sputnik-list] git

[Yuri Takhteyev]

>  This is what I have done previously (but didn't take time to script it).
>  But the idea is to invert the process :

The advantage of symlinking, in my opinion, is that it makes it easy
to mix-and-match rocks from svn and rocks installed from the remote
repository.  E.g., if I made some changes to versium and some changes
to sputnik, it is important for me to know if the new Sputnik rock
will _also_ work with the last released versium rock.  (If it does,
for example, I know I can make a new sputnik rock and release it,
leaving the new versium rock for later.)  Using your inverted process,
I will always be using the latest versium and testing sputnik-cvs-1
against versium-8.02.14 becomes harder.

Does the inverted process have any advantages compared to a script to
link/unlink rock-like directories into a repository?

>  But if rocks get multiple local rocks repository in 0.5, it would
>  obviate the question.

This won't solve the problem, though.  The issue is that I want
luarocks to see some of my svn rocks, but not all of them.

  - yuri

>  I may try it myself :
>  in the git repository
>  README
>  install.sh
>  rocks/alpha/cvs-1/alpha-cvs-1.rockspec
>  rocks/alpha/cvs-1/lua/alphamod/init.lua
>  rocks/beta/....

I would prefer a different default.

    install.sh ~/sputnik -- installs the latest sputnik from the
remote repository
    link.sh sputnik ~/sputnik -- links the sputnik rock from svn/git
into the installation
    link_all.sh ~/sputnik -- links _all_ svn/git directories into the
installation

This way you get what you want by just running two commands instead of one:

install.sh ~/sputnik && link_all.sh ~/sputnik

BTW, I have nothing against supporting site-wide installation, but I
do not want to ever treat it as the default.

-yuri

-- 
http://sputnik.freewisdom.org/