Hello all,<div><br></div><div>So the one drawback to keeping everything in one repo is, every working copy is a copy of the *whole* repository, with *all* of the history. Right now, no problem, later we might have to reconsider if cloning becomes a big chore as a result, but not for a longish time. I think it's worth trying out.</div>
<div><br><div class="gmail_quote">On Sun, Dec 30, 2012 at 4:01 AM, Juan Vuletich <span dir="ltr"><<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Angel,<br>
<br>
I really like the idea of having a single and consistent git commit of a Cuis version and all the packages that work on it. It would make much easier to go back to some date, and grab stuff that works well together. One downside is a bit more work for repo admin. A bigger one is that it makes things a slower for package maintainers. But the consistency might outweigh them.<br>

<br>
Below, I extracted Angel's comments on this. Folks, please comment. Add steps or ideas to complete or enhance Angel's suggestion. Or if you don't like it, please say why. This is a rather important decision, and I'd like we to make a good choice.<br>

<br>
One quick question for Angel (I'm a beginner with github): Can we tag a commit after it was done? That way, we could work together on Cuis and Packages for several days (involving many commits) and only when we are all happy, we can tag the last one as "v4.1 with packages" or something like that.<br>

<br>
Cheers,<br>
Juan Vuletich<br>
<br>
Angel Java Lopez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<br>
<br>
But having the central repo with the package (not a link), has an advantage: central repo could have tags. So, the packages at tag "v0.1.0" are all compatible with that tag, and every improvement at tag "v0.2.0" should be committed to that tag. The "master" tag is the development tag.<br>

<br>
So, I could download the v0.2.0 with all the optional packages of that version, without struggling going to each package author repo, and trying to guess what package/tag is compatible with Cuis v0.2.0<br>
<br>
Cons: it put more responsability to central repo author(s).<br>
<br>
<br>
<br>
    2012/12/27 Angel Java Lopez <<a href="mailto:ajlopez2000@gmail.com" target="_blank">ajlopez2000@gmail.com</a><br>
    <mailto:<a href="mailto:ajlopez2000@gmail.com" target="_blank">ajlopez2000@gmail.com</a>><u></u>><br>
<br>
        Until you have a package manager, first idea:<br>
<br>
        Use the cuis repo at GitHub.<br>
<br>
        Every contributor make a fork.<br>
        He/she add the code to his/her fork.<br>
        Make a pull request to central repo<br>
<br>
        Maybe, a guide to have folders per package/topic.<br>
        ...<br>
<br>
        Angel "MyLifeIsGitHub" Lopez ;-)<br>
        github:ajlopez<br>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org" target="_blank">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/<u></u>listinfo/cuis_jvuletich.org</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Casey Ransberger
</div>