Re: partial checkouts

[Chani <chanika@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 2950 bytes --]

On May 23, 2009 16:34:53 Johan Herland wrote:
> On Saturday 23 May 2009, Chani wrote:
> > [...]
> >
> > right now all I've thought of is one ugly hack: have a server that checks
> > out all the kde git repos, pulls daily, copies all the doc/ folders into
> > a documentation folder, and offers that folder up on the interwebs so
> > that update_xml can rsync from it or download a tgz of it or something.
> > there appear to be lots of images in the documentation, so it's not a
> > small download - 200mb and growing. it still hasn't finished downloading
> > all the externals...
>
> Do you need the doc/ folders from _all_ kde git repos, or just from those
> repos that you have currently checked out? In the latter case, you could
> solve this by adding symlinks to all the doc/ folders inside the
> documentation/ folder, and then make sure the software that traverse the
> documentation/ folder recognize and skips symlinks. Of course, this won't
> work if the translations project need _all_ doc/ folders accessible, but
> not all the kde git repos.

nope, the translators may not have checked out *any* of them but the script 
they want to run needs *all* the docs. :( however, I've been told they also 
don't want to have to change their workflow in any way at all no matter how 
small, so we may be stuck in svn-land anyways, because you can't make an svn 
external out of something that's not in svn, and having anything other than 
svn externals would change their workflow :(

>
> > I'm kinda wondering if there'd be a way to use git-filter-branch to make
> > a repo that only tracks the doc/ folder for a module - but I've no idea
> > whether it'd have to be recreated from scratch every time someone changes
> > something in the real repo's doc/
> >
> > can anyone think of a less ugly solution?
> > what are the chances of git supporting this kind of partial checkout
> > someday?
>
> Check out git-subtree. It can split out a subdirectory into its own repo,
> and re-integrate it back into the "parent" repo at a later date.
> git-subtree has been posted as a patch to this list a couple of times
> without much response, but it looks like an interesting alternative to
> submodules: http://alumnit.ca/~apenwarr/log/?m=200904#30
>
> If a lot of people find git-subtree useful, who knows, it might be included
> in a future git version.

looks interesting. might have been a solution until I heard about this 
requirement to not change workflow at all. :/

however, my friend told me about a project to make a git-svnserver that serves 
git repos as svn repos, and *that* would allow the translators to stay where 
they are without holding everyone else there too. know anything about that? 

mm, google turns up an email from someone claiming they have a partial 
implementation in python...

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]