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
18 matches
Mail list logo
