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
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
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
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
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.
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.
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
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
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
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
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
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,
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
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.
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.
http://youtube.com/watch?v=4XpnKHJAok8
is good to view if you're
16 matches
Mail list logo
