Re: More git policy: xsfbs and bundled apps packages
On Sat, Jan 13, 2007 at 01:00:34AM +1100, Drew Parsons wrote:
> David wrote:
> > On Wed, Jan 10, 2007 at 04:31:07PM +1100, Drew Parsons wrote:
> > >
> > > > The apps are fairly easy. We use the upstream* branches and just extend
> > > > it so we have individual upstream* branches for each upstream app repo.
> > > > These all get merged in to debian as the need arises.
> > >
> > > Is it as simple as that? The upstream apps are all separate repos, but
> > > for our convenience we've collected them into single packages, for
> > > instance xbase-clients (also xprint-utils and xutils). So we'd want
> > > xbase-clients managed as only one repo, at least as far as the debian*
> > > branches go, which conflicts with all the individual upstream* branches...
> >
> > We should be able to. You can test it yourself. Make a temporary repo with
> > a file "a" in it. Once this is checked in, make a second branch with a file
> > "b". Then go back to the master branch and make a third branch with a file
> > "c". Your layout will be like this then:
> >
> > branch files
> > ----- -----
> > master a
> > second a b
> > third a c
> >
> > Then you can go back to master and pull second and third in independantly.
> > You'll end up with master having files a, b, and c. This is pretty much the
> > model for these packages. Since the second and third branches are unaware
> > of each others individual files, they don't get deleted when their changes
> > are pulled in to the master branch.
> >
> > > Does it have a concept of "subrepos" where a subdirectory pulls from a
> > > different repo? I presume not otherwise this would have solved the
> > > xsfbs problem.)...
> >
> > Git doesn't have the concept of subrepos unfortunately. It'd be nice, but
> > this method should make it work. And we wouldn't have to change our
> > packaging or anything.
>
> OK, that seems to work for merging directories, although as Michel
> pointed out it's not quite the same thing as our arrangement for apps,
> where starting with
>
> branch files
> ----- -----
> master a
> second b
> third c
>
> we would want pull/merge to turn master into
> master:
> a
> second/b
> third/c
>
> Without a way of shifting directories like this in git, I can't see the
> solution to this question.
Michel spotted the problem in the scheme for the apps (which I can't
believe I missed). I tried moving the files to subdirs, but git doesn't
cope with that so well. I've been thinking about any alternate options for
a few days, but there's nothing that's really good. I see two ways forward:
1) Repackage every app individually like they were originally.
2) Just import tarballs for releases on these apps and split out any that
we might really want to keep in git.
I'm strongly leaning towards the second option. The tarballs option is fine
for these things because they're "mature" (i.e. all but dead). It's not
like it would be really hard to repackage them individually, but I don't
think it's worth it. Maybe one day we can also figure out a way to make git
handle this scenario properly. I can't think of any of the apps that we'd
particularly want to split out right now either, except maybe xrandr.
> On the other hand, doesn't this solve the xsfbs sharing problem? xsfbs
> can have its own repo, with the files in debian/xsfbs. Then any of our
> packages can git-pull that repo to get their own debian/xsfbs copy
> updated. The only difference is that this git-pull won't happen
> automatically the way it did with svn (or can a hook be created to do so?).
You've got the idea exactly. This does solve the xsfbs problem just fine,
so think we're good to go there. Basically someone would have to manually
update all the different repos with the updated version of xsfbs. We could
create a script to do this if we want. I'd be in favor of making it the
responsibility of the person changing xsfbs to also update all the repos,
at least by default, just to make sure we have some sort of expectation of
how the work is to get done. Anyone else could do it or help out, of
course.
- David Nusinow
Reply to: