On Sat, Feb 16, 2008, David Paleino wrote:
> > We’ve always done this way in pkg-gnome’s SVN, keeping only debian/
> > directories, while using simple-patchsys, dpatch, dbs (muahaha) and now
> > standardizing on quilt.
>
> ... and? Something's missing: do you use svn-do?
I wrote it for pkg-gnome
On sam, 2008-02-16 at 18:25 +0100, David Paleino wrote:
> Il giorno Sat, 16 Feb 2008 17:07:18 +0100
> Josselin Mouette <[EMAIL PROTECTED]> ha scritto:
>
> > On jeu, 2008-02-07 at 23:07 +0100, Sven Mueller wrote:
> > > However, I wonder wether quilt has any way (through a known wrapper
> > > perhap
Il giorno Sat, 16 Feb 2008 17:07:18 +0100
Josselin Mouette <[EMAIL PROTECTED]> ha scritto:
> On jeu, 2008-02-07 at 23:07 +0100, Sven Mueller wrote:
> > However, I wonder wether quilt has any way (through a known wrapper
> > perhaps) to support the thing I like (though I'm not too attached to
> > t
On jeu, 2008-02-07 at 23:07 +0100, Sven Mueller wrote:
> However, I wonder wether quilt has any way (through a known wrapper
> perhaps) to support the thing I like (though I'm not too attached to
> that feature) with dpatch:
> Being able to keep only debian/* in the repository along with the
> orig
[please CC me on replies]
-=| Damyan Ivanov, Fri, Feb 08, 2008 at 01:35:52PM +0200 |=-
> -=| Sven Mueller, Thu, Feb 07, 2008 at 11:07:00PM +0100 |=-
> > gregor herrmann schrieb:
> > > On Mon, 28 Jan 2008 09:09:28 +0100, Andreas Tille wrote:
> > >
> > >> Is there any easy conversion from dpatch to
[please CC me on replies]
-=| Sven Mueller, Thu, Feb 07, 2008 at 11:07:00PM +0100 |=-
> gregor herrmann schrieb:
> > On Mon, 28 Jan 2008 09:09:28 +0100, Andreas Tille wrote:
> >
> >> Is there any easy conversion from dpatch to quilt for a given package
> >> that is using dpatch?
> >
> > http:/
On Thursday 07 February 2008 11:07:00 pm Sven Mueller wrote:
> However, I wonder wether quilt has any way (through a known wrapper
> perhaps) to support the thing I like (though I'm not too attached to
> that feature) with dpatch:
> Being able to keep only debian/* in the repository along with the
On Thu, 07 Feb 2008 23:07:00 +0100, Sven Mueller wrote:
> > * script (but svn-centric):
> >
> > http://svn.debian.org/wsvn/pkg-perl/scripts/dpatch2quilt?op=file&rev=0&sc=0
> The script should (IMHO) make sure QUILT_PATCHES is set correctly.
> (Cc'ing dmn because of this)
Good catch, thanks!
F
gregor herrmann schrieb:
> On Mon, 28 Jan 2008 09:09:28 +0100, Andreas Tille wrote:
>
>> Is there any easy conversion from dpatch to quilt for a given package
>> that is using dpatch?
>
> The following two links might give an idea:
> * manual conversion:
>
> http://blog.orebokech.com/2007/08/c
On Jan 28, 2008 8:36 PM, Pierre Habouzit <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 28, 2008 at 10:51:06AM +, Cyril Brulebois wrote:
> > On 28/01/2008, Paul Wise wrote:
> > > maybe edit debian/patches/*.patch to remove all the dpatch comments
> > > and just leave the patch descriptions and other
Pierre Habouzit <[EMAIL PROTECTED]> writes:
> Though the "need" for --not-timestamps is really important when you
> refresh a whole patch series, and don't want spurious timestamps changes
> generating useless changes in your $SCM, and I do use it for this very
> reason.
Yes. Please use --no-t
On Mon, Jan 28, 2008 at 10:51:06AM +, Cyril Brulebois wrote:
> On 28/01/2008, Paul Wise wrote:
> > maybe edit debian/patches/*.patch to remove all the dpatch comments
> > and just leave the patch descriptions and other human-readable info.
> >
> > QUILT_REFRESH_ARGS="-p0 --no-timestamps --no-i
On 28/01/2008, Paul Wise wrote:
> maybe edit debian/patches/*.patch to remove all the dpatch comments
> and just leave the patch descriptions and other human-readable info.
>
> QUILT_REFRESH_ARGS="-p0 --no-timestamps --no-index"
Agreed on --no-index, not convinced by --no-timestamps and -p0.
FW
On Jan 28, 2008 5:09 PM, Andreas Tille <[EMAIL PROTECTED]> wrote:
> Is there any easy conversion from dpatch to quilt for a given package
> that is using dpatch?
It is as simple as:
mv debian/patches/00list debian/patches/series
rename s/\.dpatch$/.patch/ debian/patches/*
edit debian/patches/s
On Mon, 28 Jan 2008 09:09:28 +0100, Andreas Tille wrote:
> Is there any easy conversion from dpatch to quilt for a given package
> that is using dpatch?
The following two links might give an idea:
* manual conversion:
http://blog.orebokech.com/2007/08/converting-debian-packages-from-dpatch.html
Il giorno Mon, 28 Jan 2008 09:09:28 +0100 (CET)
Andreas Tille <[EMAIL PROTECTED]> ha scritto:
> Is there any easy conversion from dpatch to quilt for a given package
> that is using dpatch?
Isn't dpatch just adding a header (from "#!/usr/bin/dpatch -f" to "@DPATCH@")?
Or am I missing something? I
On Sat, 26 Jan 2008, Pierre Habouzit wrote:
Seconded. I'd add, that in fact we should standardize on quilt as an
exchange format for patches, because it's simple, and that there are
powerful tools to handle them. Basically you have almost the same power
in quilt that in many SCMs when it comes
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 a
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 alw
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
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
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
>
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 c
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
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
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.
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 us
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
f
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).
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
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 PRO
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
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
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
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
mu
35 matches
Mail list logo
