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 -- To UNSUBSCRIBE, email to debian-haskell-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120322134902.ga30...@teal.hq.k1024.org