patches-applied historical imports (usd import)

[Robie Basak]

On Mon, Jan 09, 2017 at 02:02:34PM +0000, Ian Jackson wrote:
> Robie Basak writes ("Re: patches-applied historical imports (usd import)"):
> > On Mon, Jan 09, 2017 at 01:45:52PM +0000, Ian Jackson wrote:
> > > Ideally you and I could agree on a commit structure for the imported
> > > packages, and metadata processing rules, so that the commits are
> > > identical (not just the trees).
> > 
> > By "commits are identical", are you including parent commit hashes? Or
> > just everything else?
> 
> It's true that not all of the parent hashes could be identical.

Right. In particular, our importer has two sources of input for the
unapplied branches: archive history, and rich history supplied by
developers. Commits generated by the importer end up having parents from
both of these sources (subject to source availability).

The rich history input source breaks the "reproducible commit hash"
invariant somewhat. If identical rich history is available on re-import
then the importer should produce the same result commit hash, but the
timing of supply of the rich history affects things. For example, if an
uploader forgets to give us some rich history but supplies it months
later, we still want to keep it but it will not have been adopted into
the graph of commits by the importer. But the importer would take it on
a re-import, thus mutating all subsequent commit hashes.

Right now, we're accepting rich history only for Ubuntu-specific
commits. I don't think we have really considered yet what would be best
for Debian. But in the future, if Debian is interested in the same
mechanism, then the same would apply to Debian's ancestory trees. I
don't see any reason why it wouldn't make sense for Debian to do the
same thing here.

The applied branches (created on your request) has the unapplied branch
as a parent (sort of like git-dpm does), so the same
non-reproducible-ness filters through.

> dgit imports orig tarballs in a way that is supposed to produce a
> stable commit hash for each tarball, so that different revisions of
> the same upstream version have the upstream as a common ancestor.
> 
> Does Nish's importer try to generate a fast-forwarding upstream
> branch ?  If not then part of the imported commit structure could be
> the same.

I believe it does currently, unless Nish steps in to correct me. So this
part could indeed be the same. However, I think the same rich history
case above applies here too. We're not doing it right now, but if a
maintainer wants to supply rich upstream commits (for example by
connecting upstream's VCS to the commit graph), then I think this is
something the importer could support. And in this case, the commit
hashes would start to mismatch.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20170109/dbfdd24b/attachment.sig>