On Sun, Sep 13, 2009 at 08:53:07PM +0200, Jan Vornberger wrote:
Hi there!
As I'm preparing to merge Bluetile's repository back into xmonad's mainline, I'm a little unsure how to best use Darcs for this goal. I don't have that much experience with Darcs, so I was hoping, I could get some advice on what is the best way to go about this.
So there is the public xmonad repository as well as the public Bluetile repository.
Now let's say I have two kinds of features: Some simple ones, like feature X, that can just go in unchanged. But there might also be some feature Y, where I might decide that for submission as a patch, I have to do it in a somewhat different way. So I want to revert Y and code it again as Z. How do I do this? I can think of these ways:
1. Have a new repository based on xmonad's mainline, where I incrementally pull in stuff from Bluetile's repo and polish it up. So in this case, I would pull X, but not pull Y, instead write a new patch for this repo that implements Z. Seems like a simple approach to me, but has the disadvantage, that Bluetile's repo will never get in sync with xmonad's repo, because it still has the X stuff.
I think bluetile and xmonad's repos will never be exactly in sync. There are some patches such as the renames to xmonad-bluetilebranch that we'd rather not have in xmonad, even if they're inverted. Instead, we should aim to get changes upstream and deprecate the old xmonad-bluetilebranch repo.
2. Work with Bluetile's repo and simply obliterate patch Y and implement patch Z. This seems like a bad approach, as people that might have pulled from Bluetile's repo won't notice that a patch was obliterated. It seems the Darcs manual agrees, that patches should never be obliterated, once they are public.
Usually I'd agree, but if the ultimate plan is to deprecate xmonad-bluetilebranch it is necessary to obliterate a few patches just to avoid conflicts with upstream. However, this should be done in some staging area rather than http://code.haskell.org/bluetile/xmonad/ .
3. Work with Bluetile's repo and create a reverse patch Y^-1 as well as patch Z. This has the advantage, that Bluetile's repo can get in sync with xmonad's mainline. I'm just not sure, if this is the 'darcs way' of doing things? Also, when submitting patches for feature Z, do I submit a) Y, Y^-1 and Z or b) just Z? Case a) seems like a lot of junk that shouldn't be in xmonad's mainline. But for case b) I fear, it might not be possible for some cases. Let's say the patch history looks something like: Y A B C D E F Y^-1 Z. Then later when working on A or B, it might not be possible to go without Y even so it's later reverted.
Comments? Advice?
Best regards,
Jan
From here I'd suggest that you simply create patches in the staging area, leaving the old patches unchanged. Amend-record and re-record strategies destroy project history irrevocably, and should be used only if they make
I just took a look at your repo, and this is how I'd suggest doing things: - create a branch of bluetile that is a staging area for submissions to xmonad - 'darcs obliterate' these patches related only to the development of bluetile: * Changed cabal file to call this package xmonad-bluetilebranch This allows for xmonad and xmonad-bluetilebranch to coexist until the changes are merged with upstream. * Make xmonad-bluetilebranch hidden by default to not clash with xmonad * Prepared code to go on hackage * Resolved conflict with hidden-patch * Change maintainer for this branch - 'darcs pull http://code.haskell.org/xmonad' to make sure that further patches don't conflict with upstream. the revision history very ugly. Follow similar steps for any changes you've made in contrib. This advice is geared towards preparing patches for xmonad so that 'xmonad-bluetilebranch' can be dropped in favor of mainline xmonad. This is the first time I've looked at bluetile, here are some random comments from my first look: - "half-implemented support for replacing an existing window manager". Most likely candidate for inclusion, send this in first, along with any polish you feel it needs. - PositionStore. What is this for? It doesn't seem very used in the core. Can this be a ManageHook instead? Hopefully we can get to a point where bluetile is merely an executable built on mainline xmonad, this will be easiest for you to mantain in the long run, and will help us avoid polluting xmonad's brand with a fork. Cheers, Spencer Janssen