Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Loïc Minier]

On Wed, 16 May 2007 13:52:28 +0200, Magnus Holmgren
<[EMAIL PROTECTED]> wrote:
> But since svn checkout doesn't give you the whole thing, how do you
> prefer to work (especially with respect to creating patches)? Do you
> unpack the orig tarball on top and set the svn:ignore property to ".",
> or always use 

 I do "svn-do zsh" when I plan to work on a lot of patches; this spawns
 my shell and will copy back the debian tree over the SVN checkout from
 which I ran svn-do (this script is in
 /usr/share/svn-buildpackage/contrib), but only if the exit status is 0.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Marc Haber]

On Wed, 16 May 2007 13:52:28 +0200, Magnus Holmgren
<[EMAIL PROTECTED]> wrote:
> But since svn checkout doesn't give you the whole thing, how do you 
>prefer to work (especially with respect to creating patches)? Do you unpack 
>the orig tarball on top and set the svn:ignore property to ".", or always use 
>svn-buildpackage --svn-ignore? Or do you find it easy enough to use 
>dpatch-edit-patch --debianonly? Other comments?

I usually use dpatch-edit-patch, but when I have more extensive
changes in the queue, I unpack the upstream sources besides the
debian/-only trunk and symlink debian into the upstream sources. This
is a field full of dragons, though.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Wesley J. Landaker]

On Thursday 17 May 2007 05:12:52 Magnus Holmgren wrote:
> On Wednesday 16 May 2007 14:52, Marcus Better wrote:
> > Magnus Holmgren wrote:
> > > Now, how do you combine these? Several people have thought: "The VCS
> > > can handle the changesets. Putting patches under VCS is silly!"
> >
> > I fully agree. Unfortunately Subversion doesn't make it easy for you.
> > You can keep your "patches" in different "feature branches", but it
> > gets messy since Subversion doens't keep track of merges.
>
> Is there any fundamental misdesign in Subversion that prevents that from
> being implemented somewhere in the future?

No, merge tracking has been in the Subversion roadmap for a long time, but 
has been lower priority than other things. However, merge tracking is now 
one of the highest priorities. Basic merge tracking is scheduled to be in 
the next release; more enhancements will follow.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpe1ImNx2h76.pgp
Description: PGP signature

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Josselin Mouette]

Le jeudi 17 mai 2007 à 13:12 +0200, Magnus Holmgren a écrit :
> On Wednesday 16 May 2007 14:52, Marcus Better wrote:
> > Magnus Holmgren wrote:
> > > Now, how do you combine these? Several people have thought: "The VCS
> > > can handle the changesets. Putting patches under VCS is silly!"
> >
> > I fully agree. Unfortunately Subversion doesn't make it easy for you. You
> > can keep your "patches" in different "feature branches", but it gets messy
> > since Subversion doens't keep track of merges.
> 
> Is there any fundamental misdesign in Subversion that prevents that from 
> being 
> implemented somewhere in the future?

You can use one of the svnmerge scripts instead of "svn merge" to do
things the git way.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Magnus Holmgren]

On Wednesday 16 May 2007 14:52, Marcus Better wrote:
> Magnus Holmgren wrote:
> > Now, how do you combine these? Several people have thought: "The VCS
> > can handle the changesets. Putting patches under VCS is silly!"
>
> I fully agree. Unfortunately Subversion doesn't make it easy for you. You
> can keep your "patches" in different "feature branches", but it gets messy
> since Subversion doens't keep track of merges.

Is there any fundamental misdesign in Subversion that prevents that from being 
implemented somewhere in the future?

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgp0xd84EkbeK.pgp
Description: PGP signature

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[sean finney]

tjena magnus,

just a quick anecdotal experience to throw into the thread...

for all its strengths and weaknesses, i'm pretty happy with
svn-buildpackage, mergeWithUpstream, and a debian/patches dir.  for a
long time my biggest issue with this was having to maintain these
patches across upstream changes, or introduce new patches.  

i (and i'm sure others) expressed this to the svn-buildpackage peeps,
who responded with the svn-do command (dig around in /usr/share to find
it), which i now use on a regular basis.  svn-do + quilt has more or
less[1] removed the annoyances of debian-only + debian/patches in svn.



sean

[1] there's still the issue of clutter left behind in build-area, but
nothing a cronjob can't fix up.



signature.asc
Description: This is a digitally signed message part

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Bernd Zeimetz]

Frank Küster wrote:
> Personally, I don't like branches very much.  Nobody ever explained to
> me a good receipe to handle them in the case where development proceeds
> in both, and important fixes are copied from one to the other.  

http://youtube.com/watch?v=4XpnKHJAok8
is good to view if you're interested in how the branching can work,
using git.


Best regards,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[James Westby]

On (16/05/07 13:52), Magnus Holmgren wrote:
> svn-buildpackage has a feature called "mergeWithUpstream mode", which means 
> that only the files that are actually touched are put under version control 
> (I thought most $TLA-buildpackage would have something similar, but it seems 
> to be unique to svn-buildpackage).

bzr-builddeb has this feature, it is known as merge mode there. The
README explains how to set it up, if not please file a bug.

It also has a couple of other modes that are useful if you have other
aims.

> This works well when all the differences 
> are kept inside the debian directory. The Exim maintainers work this way, for 
> example. But since svn checkout doesn't give you the whole thing, how do you 
> prefer to work (especially with respect to creating patches)? Do you unpack 
> the orig tarball on top and set the svn:ignore property to ".", or always use 
> svn-buildpackage --svn-ignore? Or do you find it easy enough to use 
> dpatch-edit-patch --debianonly? Other comments?

svn-buildpackage now includes svn-do (in /usr/share/doc I think) that
allows you to execute an arbitrary command in the full source tree.

> I my dreams you can tag individual commits and the VCS lets you extract 
> separate patches, even if there are several commits with a certain tag, 
> intermingled with commits with other tags. Dropping a particular patch (tag) 
> (when merging with a new upstream version) will be easy, even if there are 
> overlaps between patches. This should work well with the new W&P source 
> package format, and you get the best of both worlds. Maybe some of this is 
> already possible?
> 

Someone mentioned stgit, and there's mercurial queues that does the
same. These handle most of this well. What I would like to do is come up
with a system like one of these, but specialised for Debian packaging,
so that the patches are stored under debian/patches, and the information
about them is stored in the vcs. However I can't come up with a design
that I like, or even pin down the features that it should have properly.

Thanks,

James

-- 
  James Westby   --GPG Key ID: B577FE13-- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Marcus Better]

Frank Küster wrote:
> Personally, I don't like branches very much.  Nobody ever explained to
> me a good receipe to handle them in the case where development proceeds
> in both, and important fixes are copied from one to the other.

I believe git handles that, it should work nicely in most cases.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Marcus Better]

Magnus Holmgren wrote:
> I have now. IIUC, it lets you group and name diffs vs. a particular state
> of the source code, but the end result is a normal .diff.gz, meaning that
> everyone else has to use stgit too to get all the benefits, right?

Yes. People working on the same project team should use the same tools
anyway. For external people, such as when sending patches upstream, it is
trivial to extract patches.

It wouldn't be difficult to hack up a web frontend that presents the patches
in a nice way. Don't know if it exist already.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Yaroslav Halchenko]

I am not sure how would I survive without VCS (first CVS and now SVN).
And there are probably more efficient ways than I use, but I just wanted
to share.

I find mergeWithUpstream "mode" useful whenever the upstream package is
huge, and you don't want to "pollute" SVN with that much of irrelevant
for packaging files. And bringing modifications in and inspecting full
source is just 1 step away (s-b-e) after u-0 (if you don't have upstream
source readily fetched)

For inspecting .diff files I find lsdiff and interdiff very useful!
(also bash_goodies below have compare-latest which brings comparison
between two latest present builds, which come handy). Having debian
custom patches under debian/patches is a huge relief when some of the
changes propagate upstream (especially whenever with some modifications
introduced) -- you have simply to remove the patch instead of going
through the code and trying to figure out if a specific part was
due to the given 'patch'.

To help navigate between different packaging projects, and to simplify
the builds I hacked some bash helpers which are available online:
http://svn.debian.org/wsvn/pkg-exppsy/tools/bash_goodies.sh?op=file&rev=0&sc=0

Brief description:

s-b-p -- builds package under pbuilder (default to sid)
s-b-e -- svn-buildpackage --svn-export and jumps into that
 directory
totrunk   -- copies changes over to trunk/
difftrunk -- difference between current directory content and trunk

jtr  -- jumps to trunk/ of specified project.
jpb  -- jumps to pbuilder results for the project
jba  -- jumps to build-area/
jbr  -- jumps to branches/

u-0   -- uscan --upstream-version 0  -- to force fetching of the
 upstream sources using debian/watch information

queryrep filename -- queries (through ssh session) some local repository
for .deb and .dsc for some filename*. Helpful when to provide urls
to freshly built packages 
and others...

all j* commands mentioned above have completion over found PROJECTs, so
most of the time it is enough to type a first letter of the project to
get its name ;-)
without  they jump to corresponding directory of the current
PROJECT

with mergeWithUpstream I just type s-b-e, then do necessary
modifications (adjust patches), difftrunk, then (assuming that the
files are clean and all changes between current and trunk are relevant)
I do totrunk.

Cheers


On Wed, 16 May 2007, Magnus Holmgren wrote:

> I try to keep all changes to upstream as a number of patches in 
> debian/patches. I've heard that restricting the .diff.gz to ./debian is a 
> Good Thing. The drawback is that the .diff.gz becomes more difficult to read, 
> with the diff of diffs and all, but once the source package is unpacked it's 
> much easier to get an overview of the changes the maintainer has made. You 
> know all that.

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Frank Küster]

Marcus Better <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>>> "The VCS can handle the changesets. Putting patches under VCS is silly!" 
>
>> I don't agree.  With patches in debian/patches, you can give names to 
>> those files.
>
> With a VCS you can also name branches, or changesets (stgit).

Personally, I don't like branches very much.  Nobody ever explained to
me a good receipe to handle them in the case where development proceeds
in both, and important fixes are copied from one to the other.  

Or is there a VCS which would show me a three-way diff: "What has changed
between the branching point and the branch's latest revision, except
those changes which also happened between the branching point and HEAD?" 

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Magnus Holmgren]

On Wednesday 16 May 2007 14:52, Marcus Better wrote:
> > However, he can read debian/copyright and
> > debian/README.Debian to find out where the maintainer keeps his
> > repository,
>
> Or check the PTS, if you use XS-Vcs-* control fields.

Yeah, I suppose I didn't know that when I started writing my post a while ago.

> > I my dreams you can tag individual commits and the VCS lets you extract
> > separate patches,
>
> Have you looked at stgit?

I have now. IIUC, it lets you group and name diffs vs. a particular state of 
the source code, but the end result is a normal .diff.gz, meaning that 
everyone else has to use stgit too to get all the benefits, right?

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpce1QkD9DWi.pgp
Description: PGP signature

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Marcus Better]

Frank Küster wrote:
>> "The VCS can handle the changesets. Putting patches under VCS is silly!" 

> I don't agree.  With patches in debian/patches, you can give names to 
> those files.

With a VCS you can also name branches, or changesets (stgit).

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Marcus Better]

Magnus Holmgren wrote:
> Now, how do you combine these? Several people have thought: "The VCS
> can handle the changesets. Putting patches under VCS is silly!"

I fully agree. Unfortunately Subversion doesn't make it easy for you. You
can keep your "patches" in different "feature branches", but it gets messy
since Subversion doens't keep track of merges.

> However, he can read debian/copyright and
> debian/README.Debian to find out where the maintainer keeps his
> repository,

Or check the PTS, if you use XS-Vcs-* control fields.

> I my dreams you can tag individual commits and the VCS lets you extract
> separate patches,

Have you looked at stgit?

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Frank Küster]

Magnus Holmgren <[EMAIL PROTECTED]> wrote:

> Now, how do you combine these? Several people have thought: "The VCS 
> can handle the changesets. Putting patches under VCS is silly!" Maybe it is. 

I don't agree.  With patches in debian/patches, you can give names to
those files.  Names that explain what they do, and in debian/changelog
you'll use those names when closing bugs or documenting other changes.
That makes it much easier to remember why a change was made, and to
reuse the changes elsewhere (hand them over to upstream, Ubuntu, SuSE or
you mom, or just decide whether it's still needed in the development
branch).

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Michal Čihař]

Hi

On Wed, 16 May 2007 13:52:28 +0200
Magnus Holmgren <[EMAIL PROTECTED]> wrote:

> Now, how do you combine these? Several people have thought: "The VCS 
> can handle the changesets. Putting patches under VCS is silly!" Maybe it is. 
> What's for certain is, that to someone who just does 'apt-get source', the 
> VCS 
> gives no benefit. However, he can read debian/copyright and 
> debian/README.Debian to find out where the maintainer keeps his repository, 
> and reap all the benefits (I can see how a distributed system could benefit 
> downstream maintainers in particular).

XS-Vcs headers are for this. You can then see VCS location also in PTS,
e.g. .

> My question here is: *Whom* is debian/patches *for*? The maintainer or anyone 
> who wants to build a customised package, audit the package, etc?
> 
> svn-buildpackage has a feature called "mergeWithUpstream mode", which means 
> that only the files that are actually touched are put under version control 

I really like this feature. I have only debian directory in svn and
possible patches are in debian/patches. The .diff.gz is then a bit
harder to read, but after applying it is easier to get overview of
package.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature