[Xcb] A question about XCB's Git repository layout

[Josh Triplett]

Robert Bragg wrote:
> Jamey has asked me to forward this question here so everyone can
> "fight it out"
> 
> <quote>
> Basically I have been trying to put together a jhbuild moduleset for
> X.org that will pull e.g. libX11 and XCB from their new git
> repositories.

Wonderful; I would love to see something like this.

> This has gone smoothly for all git repositories except XCBs :-)
> 
> The reason stems from the facts that git doesn't seem to let you clone
> arbitrary subdirectories of a repository, and jhbuild assumes that
> there will be a autogen.sh at the top of any repository you ask it to
> check out.
> 
> To work around this locally I wrote a small patch for jhbuild that
> lets you optionally specify a particular subdirectory of a repository
> to find the autogen.sh, and that seems to work nicely for me.

Regardless of how XCB's repository finally ends up structured after this
discussion, I still think jhbuild should have this feature.

> I have passed the patch on to James Henstridge, but in his reply to me
> he had wondered if the layout of the XCB repository was ideal and if
> it could be changed. Suggesting that perhaps having separate
> repositories for each module might make it easier to deal with actions
> such as branching/merging. A minor issue I see myself is just that of
> consistency with other x.org git modules. (Probably a bit early to
> talk about consistency but e.g. libXrandr and randrproto are in
> seperate git repositories.)
> 
> On the other hand I suppose having separate repositories would require
> multiple check-in/merge procedures for widespread changes. If the
> sub-modules are tightly coupled by nature - making such changes common
> - I could see an advantage to a single repository. Interestingly if I
> understood James correctly he was suggesting that the opposite - being
> able to merge such widespread changes piecemeal - might be preferable,
> so this may all be a game of pros and cons and those with the biggest
> fists win.
> 
> I'm just curious to know if this has been considered before and
> perhaps if there are other reasons to keep it as is or otherwise?

We included it in the same repository primarily because we wanted the
ability to, in one commit, change xcb-proto and xcb, or xcb and
xcb-{demo,util}, such that you could never end up with a checked-out
combination that wouldn't work together.

However, I can definitely see advantages to the separate repository
approach as well.  In particular, since git will only tag an entire
repo, not a subtree, then tags specific to one product (xcb, xcb-proto,
etc) end up applying to all of the directories in the repository.
Similarly, branches for development of a particular product will bring
along the other products.  (The structure of a git repository, on the
other hand, causes this to require minimal space overhead at least.)

Furthermore, given that xcb and xcb-proto have far more maturity than
xcb-demo, xcb-util, and libXamine, separating them would ensure that
quality assessments of the latter group don't reflect badly on xcb and
xcb-proto. :)

We could also maintain full history in each repository quite easily.  We
would just need to clone the repository once for each product, and in
each one, rm -rf the directories for the other products.

> Finally; this was Jamey's initial response to kick things off:
> 
>> My first reaction is, "That would be painful for us and jhbuild shouldn't
>> assume that anyway," but I'd like advice from others...

I do agree entirely that jhbuild shouldn't make that assumption.  I tend
to agree with the first reaction, but I can see advantages both ways,
and I could certainly work with split repositories just fine if we want
to go that route.

- Josh Triplett

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060608/4d13a684/signature.pgp