Re: problems with 3.0 format
* Peter Krefting <peter@softwolves.pp.se> [100330 21:35]:
>> Not having that information also means that when you want to look for
>> what was changed for some bugfix, one has to look at the whole history
>> and collect the initial change and all the adoptions to newer upstream
>> versions.
>
> That's the entire point of having it in a version control system, though,
> that you can trace changes.
Well, being able to trace changes does not mean that you do not want to
be able to see the actual changes.
As Debian packages should not be forks, but only modifications that we
always hope upstream will accept or that they are at least useable by
other people or clear enough someone else can spot problems with it.
And having one commit per upstream version with the actual and complete
modification for some issue relative to that upstream version makes it
in my eyes much easier to trace the changes, than having some changeset
no longer applying to the current upstream with conflict resolution
being hidden in same merge together with resolution for all the other
changes.
>> The information about what is changed is burried in the information
>> when it was changed. It also means one cannot tell upstream or some
>> other project to just cherry-pick a specific commit to get the fix.
>
> True. But fixes generally apply anyway, until made redundant by upstream,
> so this is probably not a big problem in most cases.
In my experience that is often the case, but far too often:
- patches need to be updated to some upstream code changes
- patches change over time and get amended with more complete fixes
- patches get replaced by other patches, even partially
> git://git.debian.org/users/peterk/lyskom-server.git -
> http://git.debian.org/?p=users/peterk/lyskom-server.git;a=shortlog;h=refs/heads/debian
>
> git://git.debian.org/crashmail/crashmail.git -
> http://git.debian.org/?p=crashmail/crashmail.git;a=shortlog;h=refs/heads/debian
I think the suitability of such an approach is like the suitability of
only having a single .diff.gz in a source package.
The most practical point to see what is changed in those trees is comparing the
"New upstream release: ..." merges with their upstream side parent,
which is about equivalent to looking at the .diff.gz files of the
Debian packages generated (once one has one change, one can try to find
the commits introducing some change to get some context, but first one
has to look what changes there are and try to locate the different changes
in there).
As in those packages the non-"debian/" changes are so little, looking at
the .diff.gz gives enough information, as it is not hard to see what belongs
together and what changes there are.
Once those collects more than 1 or 2 different modifications that may
also be in the same files I do not think that scales very well. (Just as
having only a single .diff.gz would not scale that well).
Hochachtungsvoll,
Bernhard R. Link
Reply to: