On Jun 24, 3:33 pm, Tekkub <[email protected]> wrote:
> Here's my take on the whole thing...
> Conceptually, the code for your program and the website for the
> documentation... and extra pdfs and notes and... are all the same PROJECT so
> they belong in the same REPO. However, functionally, the code does not need
> to the website to function, nor does the website need the code, so they
> don't belong in the same branch. Extra files could either go in another
> branch, or simply be uploaded somewhere (GitHub) depending on their size and
> how often they change (and therefore need to be versioned). Those
> supplementary files might be something like a database backup, which you
> *really* don't want in the repo... I've been there and done that, in svn,
> and it was very painful. Putting everything in the repo isn't always the
> best thing.
Yes, I used to think of exactly that way too. I can understand . But
over time I changed my mind. It just proved to be more hassle than it
was worth. It isn't hard to exclude the docs or vice-verse when
zipping or packaging, and it proved beneficial in other ways too. For
instance my the website is versioned in sync with the rest of the
project.
> The unix perspecive... well as I see it if you want the entire project, you
> should be cloning the repo anyway. A zip is only going to give you the head
> commit... that's not really the entire project! Now, for packaged versions
> (i.e. for compilation/installation) you'd be generating a zip or an
> executable, and neither would need the web site or the supplementary
> files... if it did you'd be putthing them in the main branch. Instead, I
> would be generating two different zips for that, one for the code and one
> for the supplementary files, so the branch design fits that better for me.
> But again that's just my opinion on how to do things.
Depends on the files. I don't mind shipping a package with a useful
set of static web pages. I certainly won't bother with a separate doc
package for that. Why should I? Hard disks hold TBs these days; text
files are nothing. But say my project has a blog, that I will exclude
b/c it's not really general reference material.
> You don't necessarily have to "teach your tools about git". Take the
> website-from-code generator, you simply check out your code branch, run the
> script, checkout your website branch, and commit the files. I've done a
> similar process across repos too (the /tg path of my user Pages repo is
> generated with data from another repo entirely)... it's not as horrible as
> you might think.
It may not be especially complex, but it's still something I'd have to
do by hand and if not I have to write a tool to do it for me. I really
don't want to do anything extra at all. I'm very stubborn about
simplicity. Though it oftern takes me a while, I work very hard to
reduce everything I can to its simplest forms.
Currently I don't use Pages. Instead I upload my project sites to
Rubyforge. It takes a single rsync. In the future I hope to using
Github for everything, and I might be now, but for the Rubygems and
Pages issues.
> Oh and be warned, our todo list is very large ^^
:-( Well if there is anything I can do to expedite the issue, let me
know.
Thanks for taking the time to earnestly discuss this,
Trans.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"GitHub" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---
