Mailinglist Archive: opensuse-gnome (216 mails)
| < Previous | Next > |
Re: [opensuse-gnome] GNOME:STABLE and GNOME:UNSTABLE
- From: Michael Wolf <maw@xxxxxxxxxx>
- Date: Fri, 05 Oct 2007 09:31:44 -0500
- Message-id: <1191594704.2832.21.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Fri, 2007-05-10 at 11:40 +0200, Stanislav Brabec wrote:
> Michael Wolf wrote:
>
> > I don't propose writing our own, of course. There's no need.
>
> We even may start with osc - osc is based on svn and their authors could
> help us with accessing its svn functions.
As far as I can tell, osc is based on svn only insofar as its user
interface for checking in packages is similar.
I'm not averse to osc wrapping a proper revision control system (eg, osc
diff, osc checkin, etc being based on their hg equivalents), but I am
quite convinced that:
a) We will sometimes want or need a way to drop down into lower-level
and more powerful tools
b) Something distributed is the way to go.
> > But to say that revision control doesn't work well for packages? I
> > don't buy it.
>
> It was my practical experience.
>
> In December 2006 we branched ~280 packages to G:U to move packages
> to /usr.
>
> I did a complete backup of all packages in the branch point.
>
> G:U changed ~250 packages.
>
> Factory changed ~30 packages.
>
> There was ~30 packages with paralles changes.
>
> In late January 2007 I went to merge both branches.
>
> >From those ~30 packages, ~20 was fixed by a simple merge and ~10 had to
> be merged manually.
>
> The major problems of simple diff-patch-wiggle are:
>
> - Upstream updated package and fixed the same problem in parallel. Added
> patch is rendered obsolete.
>
> - Changes are in the same patch. Second level patch are often hard to
> apply (code change -> patch change -> second level patch cannot apply).
>
> - Changes in spec preamble often conflict - upgrade changes patch sets,
> fix does it as well. You have to merge patch set as first in order.
Right. Well, conflicts are a fact of life, whether it comes to personal
opinions or changes made to text files. :)
Also we have plans to improve our .specs so that, among other things,
it'll be obvious that a patch is expected to appear upstream and is
therefore a candidate for removal.
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-gnome+help@xxxxxxxxxxxx
> Michael Wolf wrote:
>
> > I don't propose writing our own, of course. There's no need.
>
> We even may start with osc - osc is based on svn and their authors could
> help us with accessing its svn functions.
As far as I can tell, osc is based on svn only insofar as its user
interface for checking in packages is similar.
I'm not averse to osc wrapping a proper revision control system (eg, osc
diff, osc checkin, etc being based on their hg equivalents), but I am
quite convinced that:
a) We will sometimes want or need a way to drop down into lower-level
and more powerful tools
b) Something distributed is the way to go.
> > But to say that revision control doesn't work well for packages? I
> > don't buy it.
>
> It was my practical experience.
>
> In December 2006 we branched ~280 packages to G:U to move packages
> to /usr.
>
> I did a complete backup of all packages in the branch point.
>
> G:U changed ~250 packages.
>
> Factory changed ~30 packages.
>
> There was ~30 packages with paralles changes.
>
> In late January 2007 I went to merge both branches.
>
> >From those ~30 packages, ~20 was fixed by a simple merge and ~10 had to
> be merged manually.
>
> The major problems of simple diff-patch-wiggle are:
>
> - Upstream updated package and fixed the same problem in parallel. Added
> patch is rendered obsolete.
>
> - Changes are in the same patch. Second level patch are often hard to
> apply (code change -> patch change -> second level patch cannot apply).
>
> - Changes in spec preamble often conflict - upgrade changes patch sets,
> fix does it as well. You have to merge patch set as first in order.
Right. Well, conflicts are a fact of life, whether it comes to personal
opinions or changes made to text files. :)
Also we have plans to improve our .specs so that, among other things,
it'll be obvious that a patch is expected to appear upstream and is
therefore a candidate for removal.
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-gnome+help@xxxxxxxxxxxx
| < Previous | Next > |