[rudder-dev] adding feature to a technique

[Vincent Membré]

Le 05/02/2013 14:00, Jean Rémond a écrit :
>
>
> On Tue, Feb 5, 2013 at 7:51 AM, Jonathan Clarke 
> <jonathan.clarke at normation.com <mailto:jonathan.clarke at normation.com>> 
> wrote:
>
>     On 05/02/13 13:40, Michael Gliwinski wrote:
>>     On Sunday 03 Feb 2013 16:50:59 François Armand wrote:
>>>     Michael Gliwinski<Michael.Gliwinski at henderson-group.com>  <mailto:Michael.Gliwinski at henderson-group.com>  a écrit :
>>>>     On Sunday 03 Feb 2013 13:56:14 Jonathan Clarke wrote:
>>>>>     What do you think about this versioning policy, everyone?
>>>>     This makes perfect sense.  The only drawback I can see is that finding
>>>>     history
>>>>     of changes to a file (from vcs) will become more difficult because
>>>>     pretty much
>>>>     before starting development you'll be creating a copy.
>>>>
>>>>     Unless the versioning could be somehow separated from the source?
>>>     Yeah, I'm thinking about a way to separate technique development from
>>>     versioning in Rudder, so that Dev could use any VCS they want with any
>>>     commit convention they choose, and have an other production-compliant
>>>     versioning schema alike what Jon proposed. But well, I need some more
>>>     thinking !)
>>     I know, it's hard.  I thought about it some more and the only thing I could
>>     come up with that would preserve being able to version each technique
>>     individually was to split the repository so each technique has it's own, but
>>     that's probably a maintenance nightmare :|
>
>     That is actually something we have been considering. This could
>     make sense if third parties decide to create and maintain
>     Techniques, and want to keep the "code" in their own source
>     repository (imagine some tool, like ElasticSearch or Redmine or
>     something, decides to create a Technique for Rudder to make it
>     easier for people to install their tool, but want to maintain
>     control over the Technique to be able to upgrade it for their
>     customers/users/etc).
>
>     I think last time we discussed it, we too decided it's the only
>     way to have versioning per-Technique. But to make it really easy
>     for users that don't care about changing Techniques, we should
>     present a unique git repository that assembles all the individual
>     ones (sort of a "aggregated proxy view").
>
>     This is where things get complicated, because the "git way" to do
>     this is via git-submodules, but they're a bit iffy... So we were
>     considering setting up some scripts to automate this, so that
>     everytime an individual Technique repo gets updated, we git clone
>     it, and commit it into the "unique" repo. Each directory would be
>     a git clone from the individual repos, and thus conserve
>     versioning info (git supports one repo inside another).
>
>     So, this is a possibility. It would involve quite a bit of work in
>     the Rudder web interface to be able to get Technique versions from
>     git instead of the filesystem, but it's not impossible. What do
>     you think about this approach?
>
>
>     Jonathan
>
>
>
> What about git subtree ?
> Unfortunately, it seems it does not mix well with github ...
> http://news.ycombinator.com/item?id=3926683

Having a 'master Techniques' repository embracing independant 
repositories, themselves managing an individual Technique, seems a 
wonderful idea to me and definitely something we need in Rudder!

It would provide a huge flexibility and ease the process to create and 
maintain new Techniques.

The last time we talked about this, we found gitslave, a tool that may 
fits well for that purpose : http://gitslave.sourceforge.net/index.html. 
But we need to test it in our use case to see if it works well.

Does anyone knows any drawbacks or limitations of gitslave?

Thank you Jean to point git subtree out, I have never heard of if before 
and it seems very interesting! I'll look into it to see if it fits for 
our use case!

Vincent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20130213/a3df2d0e/attachment.html>