On Sat, 2007-06-09 at 23:09 -0400, Horst H. von Brand wrote:
>
> You lost me here. If I am futzing around with the foo package, I'll have
> checked out sources /here/ and work against that. Perhaps I'll be
> following its upstream SCM, but that loses WRT pristine source tarball
> (exported version of today's changes, or even of tag 1.2.3, won't be
> exactly the released tarball foo-1.2.3.tar.bz2), so tracking all this
> centrally doesn't make much sense to me. Sure, tracking the tarballs
> making up any released RPMs is a must, otherwise I don't see the point.
Checking exploded tarballs into a VCS might work ok, but there are
issues that make that more difficult that you might first realize. Take
hypothetical project foobar, that has been developed thusly:
+-1.0 +-2.0
v v
A--B--C--D--E--F--G
\
W--X--Y--Z
^
+-3.0
Each letter represents a commit into the project's source code
repository. The numbers represent releases. Now imagine that you have
been packaging foobar for inclusion in Fedora. You have been checking
the exploded tarballs into a source code repository and end up with
something like this:
+-1.0
| +-2.0
| | +-3.0
v v v
A--B--C
Now, forward-porting your patches from 1.0 to 2.0 went relatively
smoothly, but for some reason forward-porting the patches from 2.0 to
3.0 was very difficult! If you compare the two graphs you can see that
the code in your private source code repository has a very different
history from the code in the upstream source code repository. VCSs like
Git and Mercurial can take advantage of that history to make rebasing
patches much more automatic. It's not perfect, you may end up doing
some manual, but it's a darn sight easier than doing it without the full
history.
It's true that many projects do not have the exact same content checked
into and tagged in their source code repository, but most of the time
that's not going to matter, and if it does there are methods of dealing
with that (which I won't go into now because this is already getting
long enough).
It's also true that some open source projects do not make their source
code repositories public. In that situation we'd just have to live with
checking in exploded tarballs into our source code repository.
The other point is to get the development of these patches off of the
maintainer's hard drive and into a central, public repository. Sure,
all of the patches that we apply to the pristine source are stored in
the package repository, but that's a very difficult format to work with
for anything but applying them to the code. It's especially difficult
if the patch has evolved over time and you want to look back at the
history of the patch. Have you ever tried to read the diff of a diff?
Jeff
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
