<br><br><div class="gmail_quote">On Tue, Feb 5, 2013 at 7:51 AM, Jonathan Clarke <span dir="ltr"><<a href="mailto:jonathan.clarke@normation.com" target="_blank">jonathan.clarke@normation.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>On 05/02/13 13:40, Michael Gliwinski
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>On Sunday 03 Feb 2013 16:50:59 François Armand wrote:
</pre>
      <blockquote type="cite">
        <pre>Michael Gliwinski <a href="mailto:Michael.Gliwinski@henderson-group.com" target="_blank"><Michael.Gliwinski@henderson-group.com></a> a écrit :
</pre>
        <blockquote type="cite">
          <pre>On Sunday 03 Feb 2013 13:56:14 Jonathan Clarke wrote:
</pre>
          <blockquote type="cite">
            <pre>What do you think about this versioning policy, everyone?
</pre>
          </blockquote>
          <pre>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?
</pre>
        </blockquote>
        <pre>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 !)
</pre>
      </blockquote>
      <pre>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 :|
</pre>
    </blockquote>
    <br></div>
    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).<br>
    <br>
    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").<br>
    <br>
    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).<br>
    <br>
    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?<div class="im"><br>
    <br>
    Jonathan<br></div></div></blockquote><div><br><br>What about git subtree ?<br>Unfortunately, it seems it does not mix well with github … <br><a href="http://news.ycombinator.com/item?id=3926683">http://news.ycombinator.com/item?id=3926683</a> <br>
</div></div>