Re: [PATCH] proposed v3 source format using .git.tar.gz

[Ian Jackson <ian@davenant.greenend.org.uk>]

Manoj Srivastava writes ("Re: [PATCH] proposed v3 source format using .git.tar.gz"):
> On Mon, 15 Oct 2007 17:55:13 +0100, Ian Jackson <ian@davenant.greenend.org.uk> said: 
> > Manoj Srivastava writes ("Re: [PATCH] proposed v3 source format using
> > .git.tar.gz"):
> >> Well, this is tricky. I am not sure how the NMU'er communicates with
> >> the developer; I assume it is by sending in a diff. If so, this works
> >> with an arch checked out dir, and unmodified dpkg.
> >
> > Ideally the NMUer would simply upload and would not need to send a
> > diff to the BTS.
> >
> > The maintainer would fetch the source from the archive and would be
> > able commit the NMUers changes and then merge etc. appropriately.
> 
>         This works better for the distributed VCS's with the model that
>  every checkout contains a copy of the whole repository. With a
>  distributed model where every checkout does not pull in a copy of the
>  repo, this means the NMU'er would have to have write access to the repo
>  (unlikely), or create their own public repo with tagged version of the
>  software, or send in a diff.

I was talking about the case where the NMUer is RCS-naive.

They download the source edit it, test it, and upload it, all using
using the standard tools (apt-get source, dpkg-source,
dpkg-buildpackage etc.),

Obviously this means that the NMUer's download, and their
corresponding upload, have to contain a working tree.  By this I mean
it has to contain, or imply in a way that the tools can construct,
both a complete set of the actual checked-out source code, and also an
indication of what the version was that was checked out (the
information that CVS puts in the CVS/Entries file) so that it can be
merged properly later.

Ian.