Re: problems with 3.0 format

[Bernhard R. Link]

* Peter Krefting  [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


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100331090045.ga19...@pcpool00.mathematik.uni-freiburg.de

Re: problems with 3.0 format

[Peter Krefting]

Bernhard R. Link:

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.


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.



This is how I use Git to track changes (The "debian" branch holds the Debian 
patches). As in your example, the Git history has been re-created from 
previous package releases:


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 haven't yet tried to use any automated tools to make packages from these, 
curerntly I just use dpkg-buildpackage and tell it to ignore the .git 
directory when building.


--
\\// Peter - http://www.softwolves.pp.se/


--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1003302127250.25...@perkele.intern.softwolves.pp.se

Re: problems with 3.0 format

[Manoj Srivastava]

On Mon, Mar 29 2010, Bernhard R. Link wrote:

> * Peter Krefting  [100328 18:25]:

>> Unfortunately, such a workflow can't easily be translated back into a set
>> of patches to apply on top of the current upstream.
>
> I think it is a worse problem than only the impossiblity to create the
> patches. That is only a consequence of the version control system
> missing information about what the changes are.
>
> 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. 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.

I am working on a script that given two tree-ish objects, forks
 off a temporary branch of the first tree-ish object, rebases it onto
 the second tree-ish object, Creates a patch series, and deletes the
 temporary branch. I am doing this partially for work (which uses a
 hacked together git-to-perforce  kludge), and partially to feed feature
 branches upstream more easily, while preserving history.

It would be nice f I can also detect and squash merge nodes from
 the temporary branch.

With this script, I think that merge workflow would become more
 viable.

manoj
-- 
Drop the vase and it will become a Ming of the past. The Adventurer
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w9bfbxg@anzu.internal.golden-gryphon.com

Re: problems with 3.0 format

[Bernhard R. Link]

* Peter Krefting  [100328 18:25]:
>> Up to know I was rather thinking of designing a new tool
>> "vcs-buildpackage" but maybe I simply want to create new source
>> formats "3.0 (git2quilt)" or "3.0 (bzr2quilt)" and extend the dpkg-source
>> integration in dpkg-buildpackage.
>
> That only works if you use a rebase workflow in the VCS, not if you use a
> merge workflow. Personally, I find merge workflows easier to follow,
> since you can track the branch back through history properly.

History with rebased branches is indeed the tricky point.
I know of two possibilities:
 - Either rebase and merge that one (possibly with -s ours).
   The problem with that is that git's format patch (and all the
   rebase operations) have problems coping with that.
 - don't publish the patched branch but only tag when released and
   include in the history of some debian branch. (That is what git-dpm
   does). (Try to clone git://git.debian.org/users/brlink/xwit.git and
   take a look at the history. I've tried to import the old history in
   a way like it would be created when using git-dpm workflow.) I think
   it is relatively easy to follow such a history. (And pointing someone
   to the specific tag in git.debian.org's web-view is as useable for
   someone to look at the actual changes as viewing the patches with
   patch-tracker.debian.org is).

> Unfortunately, such a workflow can't easily be translated back into a set
> of patches to apply on top of the current upstream.

I think it is a worse problem than only the impossiblity to create the
patches. That is only a consequence of the version control system
missing information about what the changes are.

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. 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.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100329115521.ga...@pcpool00.mathematik.uni-freiburg.de

Re: problems with 3.0 format

[Peter Krefting]

Raphael Hertzog:


Up to know I was rather thinking of designing a new tool
"vcs-buildpackage" but maybe I simply want to create new source
formats "3.0 (git2quilt)" or "3.0 (bzr2quilt)" and extend the dpkg-source
integration in dpkg-buildpackage.


That only works if you use a rebase workflow in the VCS, not if you use a 
merge workflow. Personally, I find merge workflows easier to follow, since 
you can track the branch back through history properly. Unfortunately, such 
a workflow can't easily be translated back into a set of patches to apply on 
top of the current upstream.


--
\\// Peter - http://www.softwolves.pp.se/


--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1003281723060.14...@perkele.intern.softwolves.pp.se

Re: problems with 3.0 format

[Raphael Hertzog]

On Sun, 28 Mar 2010, Bernhard R. Link wrote:
> I don't think that this would be very useful. VCS usage can vary quite a
> bit and more often then not will not contain any usefull information.
> (like some branch just always merged with the upstreams has not much
> information except the diff to the unmodified version).

Huh? For the same reason that it's good to standardize on one patch
system, I think it would be good to promote a small set of sane VCS-based
workflows so that people don't have to evaluate all external
*-buildpackage helpers and their associated workflows when they want to
start using a VCS for package maintenance.

That said, we're still in the experimentation stage when it comes to VCS
and package maintenance so it might be a bit early to integrate it in
dpkg-dev. But there's no reason we couldn't experiment in dpkg-dev itself,
provided that we make it clear that things might change in incompatible
ways.

> Back to how dpkg-source can help: What I'm missing (don't know if this
> is a feature request or a request for better documentation) is some
> option to tell dpkg-source (ideally in a way that is already passed down
> from dpkg-buildpackage) that in case of a "3.0 (quilt)" package no new
> patch should be created but if there are changes not yet recorded in
> debian/patches it should abort with an error.

There's no such option currently. But you can pass arbitrary options to
dpkg-source from dpkg-buildpackage since 1.15.6.

Feel free to submit a wishlist bugreport for this. But I expect that
the easiest to implement will be to fail if
debian/patches/debian-changes- is about to be created.

> And it would be nice if .gitattributes would be ignored like .gitignore.

Committed to git.

> And if it would not include debian/.git-dpm into the debian.tar.gz by default,
> too.

Hum, I'm more reluctant for this one. I suggest you put “tar-ignore =
"debian/.git-dpm"” in debian/source/options.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100328141026.ga16...@rivendell

Re: problems with 3.0 format

[Bernhard R. Link]

* Raphael Hertzog  [100328 11:44]:
> On Sat, 27 Mar 2010, Bernhard R. Link wrote:
> > I'm guess this discussiong is slowly leaving debian-dpkg@ topic,
> > though...
>
> Definitely not. I plan to integrate VCS knowledge in dpkg-dev at some
> point and I like those discussions so that I can make up my mind on what's
> best.

I don't think that this would be very useful. VCS usage can vary quite a
bit and more often then not will not contain any usefull information.
(like some branch just always merged with the upstreams has not much
information except the diff to the unmodified version).

Back to how dpkg-source can help: What I'm missing (don't know if this
is a feature request or a request for better documentation) is some
option to tell dpkg-source (ideally in a way that is already passed down
from dpkg-buildpackage) that in case of a "3.0 (quilt)" package no new
patch should be created but if there are changes not yet recorded in
debian/patches it should abort with an error.

And it would be nice if .gitattributes would be ignored like .gitignore.
And if it would not include debian/.git-dpm into the debian.tar.gz by default,
too.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100328111059.ga6...@pcpool00.mathematik.uni-freiburg.de

Re: problems with 3.0 format

[Raphael Hertzog]

On Sat, 27 Mar 2010, Bernhard R. Link wrote:
> I'm guess this discussiong is slowly leaving debian-dpkg@ topic,
> though...

Definitely not. I plan to integrate VCS knowledge in dpkg-dev at some
point and I like those discussions so that I can make up my mind on what's
best.

Up to know I was rather thinking of designing a new tool
"vcs-buildpackage" but maybe I simply want to create new source
formats "3.0 (git2quilt)" or "3.0 (bzr2quilt)" and extend the dpkg-source
integration in dpkg-buildpackage. Those new formats would create a "3.0
(quilt)" source package but would require a git or bzr repository to do
its work.

We could create debian/source/local-options to contain the options that should
not be incorporated in the exported source package and which are really
specific either to the VCS or to the maintainer preference.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100328094342.gh14...@rivendell

Re: problems with 3.0 format

[Bernhard R. Link]

* Colin Watson  [100327 17:00]:
> > I think what quilt is missing here, is some reverse-setup: A command
> > to create a .pc file from a patched tree and a series of patches.
>
> Are you suggesting specifically here that this should go in quilt?  I
> wouldn't be opposed to that; I'd been thinking of dpkg-dev, but either
> would work.

I've missed that functionality already in quilt before the 3.0 format
came, so I personally would suggest to have it in quilt.

> > Another way to work around that is not using quilt if you are using
> > a vcs, but use the vcs to manage the differences and export that
> > information into debian/patches/.
> > For git I wrote git-dpm[1] as some way[2] to do this. I guess with bzr
> > something similar should be possible.
>
> I know some people have been looking at this, and I recognise that in
> many ways it would be better to regard the patches as exports from a VCS
> (indeed, I mentioned this in my blog article).  However, for me, I'd
> foresee many more warts than the mere management of branches and
> extraction of patches from them.  For instance, I would want to commit
> debian/changelog at the same time as the patch (I don't like
> autogenerating debian/changelog; the results tend to be terrible), which
> means I'd have to either tolerate lots of conflicts or else put up with
> auto-merging tools, which I never really trust very much.

I like to have the patch without the debian/ related changes (so
upstream or other users can cherry-pick it).

In git-dpm workflow:
git-dpm checkout-patched
apply patch/modify files
git commit
git-dpm update-patches
dch "description"
# possible other debian/ changes
git commit -a --amend

so the commit that has the changed debian/patches (and the virtual branch
with the actual changes as parent) also has the debian/changelog
changes.

> Also there's
> the issue of DEP-3 metadata in patch files, which I'd often want to
> change along with the commit to their contents.  Probably all soluble
> but all the tools I've seen are very definitely in their early stages as
> yet.

I try to just have them in the git commit description. I'm not using
them very consistently yet, though.

> > When using git, moving the patches to a new upstream is just a rebase
> > of a patched branch to a new upstream. That means if the patches are
> > stored as commits those commits can be rebased and one has the changes
> > and information to create the updated patches from created by the same
> > resolution. Perhaps something like that is possible with bzr, too.
>
> Well, firstly, I strongly disapprove of rebasing published branches, so
> I'll mentally s/rebase/merge/g (though either is of course perfectly
> possible with bzr).

I'd prefer if the commits are usable to be reused by upstream. Rebased
stuff usually is, while something merged and merged again is usually
nothing upstream will want to pull.

My solution against the "rebasing published branches" is thus to not
publish it as branch, but only as tag and as part of the history of the
debian branch (and of course as temporary branch for the user doing the
modification).

I'm guess this discussiong is slowly leaving debian-dpkg@ topic,
though...

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100327190305.ga2...@pcpool00.mathematik.uni-freiburg.de

Re: problems with 3.0 format

[Colin Watson]

On Fri, Mar 26, 2010 at 11:50:40AM +0100, Bernhard R. Link wrote:
> * Benjamin Drung  [100326 01:54]:
> >  1. It's a bit awkward to set things up when checking out from
> > revision control; I didn't really want to check in the .pc
> > directory, and the tree checks out in the patched state (as it
> > should), so I needed some way for developers to get quilt
> > working easily after a checkout. This is sort of the reverse of
> > the previous problem, where users had to do something special
> > after dpkg-source -x, and I consider it less serious so I'm
> > willing to put up with it. I ended up a rune in debian/rules
> > that ought to live somewhere more common.
> 
> I think what quilt is missing here, is some reverse-setup: A command
> to create a .pc file from a patched tree and a series of patches.

Are you suggesting specifically here that this should go in quilt?  I
wouldn't be opposed to that; I'd been thinking of dpkg-dev, but either
would work.

> Another way to work around that is not using quilt if you are using
> a vcs, but use the vcs to manage the differences and export that
> information into debian/patches/.
> For git I wrote git-dpm[1] as some way[2] to do this. I guess with bzr
> something similar should be possible.

I know some people have been looking at this, and I recognise that in
many ways it would be better to regard the patches as exports from a VCS
(indeed, I mentioned this in my blog article).  However, for me, I'd
foresee many more warts than the mere management of branches and
extraction of patches from them.  For instance, I would want to commit
debian/changelog at the same time as the patch (I don't like
autogenerating debian/changelog; the results tend to be terrible), which
means I'd have to either tolerate lots of conflicts or else put up with
auto-merging tools, which I never really trust very much.  Also there's
the issue of DEP-3 metadata in patch files, which I'd often want to
change along with the commit to their contents.  Probably all soluble
but all the tools I've seen are very definitely in their early stages as
yet.

It seems to me that I could easily end up spending all the time I save
on playing with tools, which isn't really what I want to be doing.

> >  2. Although I haven't had to do it yet, I expect that merging new
> > upstream releases will be a bit harder. bzr will deal with
> > resolving conflicts in the patched files themselves, and that's
> > why I use a revision control system after all, but then I'll
> > have to go and refresh all the patches and will probably end up
> > doing some of the same conflict resolution a second time.
> 
> When using git, moving the patches to a new upstream is just a rebase
> of a patched branch to a new upstream. That means if the patches are
> stored as commits those commits can be rebased and one has the changes
> and information to create the updated patches from created by the same
> resolution. Perhaps something like that is possible with bzr, too.

Well, firstly, I strongly disapprove of rebasing published branches, so
I'll mentally s/rebase/merge/g (though either is of course perfectly
possible with bzr).  bzr certainly has all the pieces required to do
this (especially with looms, which share some properties with git-dpm),
although a bit of assembly would be required.  Still, I've managed this
sort of thing in the recent past with git and I found that I hit
cognitive overload very quickly past about half a dozen topic branches,
even with tool assistance, so I think the 30-odd in OpenSSH would
probably make my brain melt.

As I said in my blog, I think doing this in a DVCS is almost certainly
the right answer for some point in the future, but right now I think I
would rather not be spending lots of time on experimental tools.  'quilt
pop -a && bzr merge --force' followed by repeated quilt push, resolve,
quilt refresh is distinctly suboptimal, but it at least has the virtue
of simplicity - all the bits are right out on view and it's easy to back
out if something goes wrong.  With due respect to git-dpm, all the
experimental VCS tools I've seen for this right now still sort of remind
me of managing this stuff with vendor branches in CVS, which is not a
level of involvement with my tools I want to return to. :-)

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100327155940.gb24...@master.debian.org

Re: problems with 3.0 format

[Colin Watson]

On Fri, Mar 26, 2010 at 01:53:56AM +0100, Benjamin Drung wrote:
> as requested in the Lintian tag, here comes an email describing some
> problems with 3.0 format. I encounter the same problems like Colin
> Watson [1]. Quote:

Note that I did file a bug about this (linked from my blog).  The blog
was rumination and mostly praise; the substantive criticism went in a
bug report. :-)

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100327154214.ga24...@master.debian.org

Re: problems with 3.0 format

[Raphael Hertzog]

On Fri, 26 Mar 2010, Russ Allbery wrote:
> I think the combination of --single-debian-patch and
> debian/source/patch-header will let me collapse the changes into one patch
> while still preserving the other features of 3.0 (quilt), but I'm not
> completely sure what happens if someone then downloads such a package,
> hacks on it more, and then builds a new source package.  Are their changes
> incorporated into my same patch with my same header?

If you put --single-debian-patch in debian/source/options, yes, because
they will also build the source package with the same option. If you use
that option on the command line when building the source package, then no.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100326210055.ga11...@rivendell

Re: problems with 3.0 format

[Russ Allbery]

"Bernhard R. Link"  writes:

> Another way to work around that is not using quilt if you are using a
> vcs, but use the vcs to manage the differences and export that
> information into debian/patches/.  For git I wrote git-dpm[1] as some
> way[2] to do this. I guess with bzr something similar should be
> possible.

My perspective, as someone who uses Git to manage changes relative to
upstream, is that this is pointless makework unless one has some
expectation that there's some consumer for these patches.  For OpenAFS,
for instance, where I regularly cherry-pick changes from the upstream
release branches, those patches correspond to upstream deltas that are
available from upstream, and exposing them as separate patches in
debian/patches just requires that I do extra work that no one cares about
or will ever look at and makes my life harder when merging new upstreams.

I think the combination of --single-debian-patch and
debian/source/patch-header will let me collapse the changes into one patch
while still preserving the other features of 3.0 (quilt), but I'm not
completely sure what happens if someone then downloads such a package,
hacks on it more, and then builds a new source package.  Are their changes
incorporated into my same patch with my same header?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ocia6dqw@windlord.stanford.edu

Re: problems with 3.0 format

[Bernhard R. Link]

* Benjamin Drung  [100326 01:54]:
> as requested in the Lintian tag, here comes an email describing some
> problems with 3.0 format. I encounter the same problems like Colin
> Watson [1]. Quote:
>
>  1. It's a bit awkward to set things up when checking out from
> revision control; I didn't really want to check in the .pc
> directory, and the tree checks out in the patched state (as it
> should), so I needed some way for developers to get quilt
> working easily after a checkout. This is sort of the reverse of
> the previous problem, where users had to do something special
> after dpkg-source -x, and I consider it less serious so I'm
> willing to put up with it. I ended up a rune in debian/rules
> that ought to live somewhere more common.

I think what quilt is missing here, is some reverse-setup: A command
to create a .pc file from a patched tree and a series of patches.

Another way to work around that is not using quilt if you are using
a vcs, but use the vcs to manage the differences and export that
information into debian/patches/.
For git I wrote git-dpm[1] as some way[2] to do this. I guess with bzr
something similar should be possible.

>  2. Although I haven't had to do it yet, I expect that merging new
> upstream releases will be a bit harder. bzr will deal with
> resolving conflicts in the patched files themselves, and that's
> why I use a revision control system after all, but then I'll
> have to go and refresh all the patches and will probably end up
> doing some of the same conflict resolution a second time.

When using git, moving the patches to a new upstream is just a rebase
of a patched branch to a new upstream. That means if the patches are
stored as commits those commits can be rebased and one has the changes
and information to create the updated patches from created by the same
resolution. Perhaps something like that is possible with bzr, too.

Hochachtungsvoll,
Bernhard R. Link

[1] http://git-dpm.alioth.debian.org/
[2] The biggest problem with storing the patches as commits is that
patches should not describe the history but the changes. While
this can be done in git nicely via usage of git rebase -i, git
has some problems storing[3] the history of rebased branches in the
history of some branch, so git-dpm is mostly some magic to have
the patched branch only as temporary git branch but otherwise
only as virtual branch contained in the history of some debian
branch.
[3] well, storing is possible, but only in a way hard to deal with...


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100326105040.ga21...@pcpool00.mathematik.uni-freiburg.de