On Thursday, August 30, 2012 1:04:56 PM UTC+2, Haasip Satang wrote: > > Thanks Thomas, > > I was looking into these Jenkins options as well, but as you said > yourself, it would be kind of a "short-term hack" and definitely would have > big impact on our feedback loop as we have a whole bunch of projects and > branches and of course would like to get timely feedback. (which is hard > with only one Executor ;-) ). >
You can go beyond this limitation by having several build nodes: *Jenkins-node 1** (with one executor)* /workspace/big-repo *Jenkins-node 2 (with one executor)* /workspace/big-repo Now. two example jobs: *Job: Foo* Custom workspace: /workspace/big-repo *Job: Bar* Custom workspace: /workspace/big-repo Now these two jobs can build in parallell, and will use the respective workspace on their own build node. As for the hard links, please see my reply to Philips answer above. I don't > understand why cloning locally (with file:// prefix though) leads too a > small repository while cloning from remote results in a big one. When I > clone the small local clone again from remotely though, it stays small and > I end up with what I want to have... just that I need to jump across too > many repos: > This is just an optimization Git does on filesystems that support hardlinks. Quoting the "--local" option from git clone: * --local, -l* *When the repository to clone from is on a local machine, this flag > bypasses the normal "git aware" transport mechanism and clones the > repository by making a copy of HEAD and everything under objects and refs > directories. The files under .git/objects/ directory are hardlinked to save > space when possible. This is now the default when the source repository is > specified with /path/to/repo syntax, so it essentially is a no-op option. > To force copying instead of hardlinking (which may be desirable if you are > trying to make a back-up of your repository), but still avoid the usual > "git aware" transport mechanism, --no-hardlinks can be used.* If you again combine this with the sparse checkout, you will be saving a lot of space. If I went for this approach, I wouldn't bother with subtrees at all. About splitting up to small repos... yes, would love to do that... the > problem is more of political nature at the moment and we are having to > merge sources between clear case and git all the time for now (which > sucks!!!). So have the whole clear case view under git control as well just > makes this already cumbersome process a lot easier for us. Don't see that I > will be able to change that anytime soon until some people finally > understand that it just doesn't make sense and git is definitely a good > thing and can be used on enterprise scope projects (as all the references > we gave are not enough ;) )... anyway... let's not go there... as I said... > politics ;( > > I think we've all been there :) -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/R-j9qSeC7dQJ. To post to this group, send email to email@example.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.