Re: Minutes of the pkg-perl BoF at DebConf 10
On Aug 7, 2010, at 23:05, Ansgar Burchardt wrote:
> أحمد المحمودي <aelmahmoudy@sabily.org> writes:
>
>> On Sat, Aug 07, 2010 at 05:50:35PM -0400, gregor herrmann wrote:
>>> Ansgar asks do we need checkouts of the whole tree?
>>> D. Bremner: Yeah, we'd most likely need to do that.
>> ---end quoted text---
>>
>> If the transition to git would be done, would that mean that all
>> packages will be in the same git repo ? Or each package will reside in
>> its own git repository. Please note that due to the nature of git, one
>> needs to checkout the whole tree, which will be too much download size
>> if all packages will be in the same git repo.
>
> Every package will have its own repository. I think we all agree on
> this and it is also how the packages we already have in Git are handled
> today.
I think that we might want to at least consider storing 'trunk' in a single git instance. Here's why;
- git focuses on the changes, not the entire tree.
This means that any change in the full tree will be merged back, not the whole tree. So you won't be sending the entire tree over the network.
- There is a new http(s) git backend making the git easier to use over http and eliminating ssh keys.
This is not such a real advantage because the way we use our ssh keys is already established and works well.
- git allows for complete recreation of the _entire_ repository
As long as all the parts of the repo are somewhere, we can create the whole repo. If the svn repo disk crashes, and someone does not have the whole tree checked out, it's gone.
- it solves multiple edits better allowing for a more flexible workflow
Having simultaneous multiple commits is really more of a problem in a centralized repository. With git, you update your repo and merge your changes back locally first, thereby ensuring that you will not break anything.
- the perl binary in debian is maintained this way
We can share expertise and experience with Nike and others who use this work flow.
I think it is something to think about but I suspect someone will have to pull in the entire repo into git and do some testing so we have some hard data to discuss. I'm willing to do this - is there a set of examples I might use as benchmarks? I.e. a complex merge or typical workflow, or some problem git might solve that svn doesn't that people think it would be useful to know about?
For the individual packages we might be able to use submodules.
>
> Having a single, large repository will have several disadvantages:
> · hard to remove single packages including history (license problems,
> should be rare as long as we are allowed to distribute the package
> even when its not DFSG-free),
> · lots of merges when people work on different packages at the same
> time,
> · it's, well, larger.
>
> But we still want to have whole-tree checkout. And it should be
> reasonably fast to update this.
git is designed to do this, and designed to do it quickly. I can almost assure you that any update of the whole trunk will be an order of magnitude faster in git if the whole tree is checked out. But of course my argument is stronger if I have some data I can point to.
Jeremiah
Reply to: