patches-applied historical imports (usd import)

[Robie Basak]

On Mon, Jan 09, 2017 at 05:17:08PM +0000, Ian Jackson wrote:
> Robie Basak writes ("Re: patches-applied historical imports (usd import)"):
> > 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.
> 
> When Debian has its own complete and ongoing git history, with a
> mixture of rich and imported histories, you will obviously want to
> fold that into your ongoing Ubuntu history.  How do you plan to do
> that ?

Using the same "adopt rich history" mechanism. Give the importer, in
advance, a map of (srcpkgname, versionstring) -> (commithash). When the
importer imports, if the map lookup succeeds, the corresponding commit
is added as an additional parent.

Then the question just becomes: whence do we get this map? Right now one
mechanism is that the uploader provides it to the importer repository in
advance via a tag. We could also use the dgit-like mechanism of putting
a commit hash in the changes file together with some known place to find
that commit object.

Further mechanisms might be able to locate a commit object by following
a Vcs-Git header and expecting a dep14 tag there, though I think this
needs some thought about safety and edge cases (repository unavailable,
etc).

Ultimately either we agree on a known way to find the commit objects, or
we rely on uploaders to provide them, or we do not get the rich history.

If Debian does not provide a mechanism for the importer to pick this up
automatically (or we cannot use it for whatever reason), an Ubuntu
uploader could still manually pull in Debian VCS history by preparing a
commit that uses Debian VCS in its history, and providing that as the
"rich history commit object" to the importer before uploading to Ubuntu.

Does this answer your question? I'm not sure what else you're looking
for here.

> > 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.
> 
> Indeed.  I don't think this can be made perfect but the more we make
> it similar the better.
> 
> dgit's imports of tarball are always origin commits, with a separate
> commit to stitch them into history.  That allows for a different
> import of the same tarball to have different parents, but still share
> the same tarball origin commit.

Ah. We could do the same then, to use the same tarball origin commit
hash. That might be useful.

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/ee5233b2/attachment-0001.sig>