On Mon, Oct 08, 2007 at 03:59:05PM -0500, Manoj Srivastava wrote: > > Where it starts becoming relevant (afaics) is when there's a > > Debian-specific patch history (either due to it being a native > > package, complicated packaging, or significant patches against > > upstream) and we want the archive, as the primary way we distribute > > the source, to include a real change history rather than a simple > > snapshot. > This seems to fit my use case; I have often large feature > branches that only sporadically get merged back upstream. Right, but the caveat is important too -- we have to _also_ want the archive to include the real change history. Maybe when things get complicated enough that there are "often large branches that sporadically get merged back", that part's no longer worth the hassle: > This is almost an order of magnitude increase in size, which I > find hard to justify. As far as cases where there are enough changes to make a repo interesting, but not so many that shipping a repo as the standard source becomes huge and clunky, it's possible that arch just isn't a useful tool for the job -- repo registration alone would be pretty annoying, and it's not like there aren't plenty of other VCS options for that case anyway. Subversion (or SVK) isn't an option either, afaics, eg, and I doubt CVS or RCS would work well either. So that leaves: > I still think that shipping a full working dir, with no dpkg > changes, seem to be the way to go, along with a tla grab file, which I > think I should consider putting into the package itself (If I can work > around the chicken and egg issue of adding a grab file changes the > source revision which means the grab file should change which means a > new revision is needed ....) If you're just distributing a snapshot, rather than a full repository as Joey's basically proposing, why can't your grab file be autogenerated? ie, 1. hack on the source, merge changes, blahblah, finish, tag 2. do a checkout from version control 3. autogenerate anything necessary 4. create source package 5. build 6. upload If you're using pristine-tar to create a pristine .orig.tgz from your repo (rather than keeping one around), that needs to be autogenerated at step 3 too, afaics. Worst case you could check the autogenerated files into a parallel repository and use a config or something, afaics. Cheers, aj
Attachment:
signature.asc
Description: Digital signature