Re: Feasibility of backports?
On Thu, Mar 22, 2012 at 02:35:41PM +0100, Joachim Breitner wrote:
> Hi,
>
> Am Donnerstag, den 22.03.2012, 12:38 +0100 schrieb Iustin Pop:
> > > > A policy/technical question now: let's say we have backports for one
> > > > package (either just one or out of many). With git-buildpackage, I'd
> > > > just use a bpo-squeeze branch, which would be trivial to setup. How does
> > > > this work with darcs? I'm reading http://wiki.darcs.net/BestPractices
> > > > and it seems to say it doesn't support _any_ kind of multiple branches
> > > > in one repository?
> > >
> > > No, in Darcs, a repository is a branch (in a way similar to SVN, where
> > > branches are directories in the virtual SVN tree). So what I did for
> > > expeirmental is to clone the repo and put it
> > > in /darcs/pkg-haskell/experimental – you can do the same
> > > with /darcs/pkg-haskell/squeeze-backports.
> >
> > Ah, I see, one repo/directory per package under that?
>
> Correct.
>
> > I would guess there's no nice merge/cherry-pick between the repos then.
>
> Why? Cherry-picking was invented by Darcs (or so I have been told :-))
Heh, didn't know that :)
> Just say
> $ darcs pull path/or/url/to/other/repo
> and it will interactively allow you to cherry-pick the changes.
Ah, I was referring more to the following:
- edit something on the sid branch (e.g. control)
- checkout bpo-squeeze
- run git merge: it will do the right thing to pick up that change only,
in a seemingly "automated" way
That small difference aside, if darcs manages that (pulling) nicely,
excellent!
> And the
> great thing is: The cherry-picked change will be logically the same (not
> just similar as in git), as the order of patches is not fixed in Darcs.
Ooh, this is nice, indeed. Didn't know that.
> (It can get slightly less nice if there are conflicts, e.g. due to the
> debian/changelog entries.)
That's the same with git TBH.
> > Not speaking down on Darcs, just that with git-buildpackage this
> > workflow seems more mature. On the other hand, upstream sources not kept
> > in Darcs, so it is simpler in this model, and you don't need to merge
> > that much.
>
> I get to differ. git-buildpackage has always been a PITA to me, mostly
> due to it trying to use more than one git branch for _one_ line of
> development (master, upstream, tar-pristine); I had to manually clean up
> so often. For example, if you use "debcheckout" you will not have all
> branches set up correctly. The fact that git-buildpackage has dedicated
> pull and clone commands shows that the workflow is not good.
Since I don't know Darcs, I'll learn more first before making more
comments :) I didn't have problems with gbp though, just learned the
workflows and it was fine for me.
Just to clarify something, since we talk about debcheckout: should a
backport, since it uses a different VCS, update the Vcs-* entries? They
are not critical, but I think they should be.
thanks,
iustin
Reply to: