Yup, I like 'em for that reason as well. And you can do a
bk clean # removes all non-modified working files
ls # should see nothing but SCCS/
to clean up all that extra cruft that invariably winds up in your tree.
> I would have to agree. Ted uses BK for e2fsprogs, and there have been
> several times when I try to send him a CSET, but he is unable to apply
> it because it is missing dependencies, even though I know those prior
> CSETs are actually independent changes that just happen to touch the
> same files.
Please see the response to Ingo and see if you could do what I suggested
there. I believe that would work fine, if not, let me know.
> Also, (BK feature request time) there are times when I've done a 'bk citool'
> and committed a bunch of changes into a CSET, and later on done some more
> testing which revealed a bug or found that I'd forgotten to change the
> man page to track the changes I made. I'd much rather be able to merge
> some more changes into the same CSET instead of creating a second CSET and
> now have two CSETs to ship around for what is logically a single change.**
In the next release, there is a "bk fix -c" that does what you want. It
reedits the entire changeset, and preserves all your checkin comments.
You don't want to use this if the changeset has propogated out of your
tree, but I use it all the time for exactly the situation you describe
above. It will be in bk-2.1.4.
> I think it would quickly become a nightmare if you had to submit (and
> have accepted!) all of your changes to Linus IN ORDER. As it stands now,
> there are lots of discrete changes I have in my ext2 tree, and whenever
> I get around to it or when people hit the same bug as me I generate a
> patch, edit out the irrelevant parts, and send it out.***
Yeah, we know. Read the other mails and tell me if you think that the
false dependency remove largely fixes this, somewhat fixes it, or doesn't
help.
> Granted, it is hard to keep distributed BK repositories consistent if you
> apply patches out of order, but at the same time, this is how development
> works in real life. Two solutions I can see to this:
>
> 1) Allow out-of-order CSET application (maybe with some sort of warning
> that Linus can turn off, because _every_ CSET he would get would be
> missing dependencies from somebody's tree).
This one is unlikely to happen, it is a much harder problem technically than
it appears on the surface.
> 2) Allow "proxy" CSETs to be included which say "the changes from adilger
> adilger@lynx.adilger.int|ChangeSet|20011226061040|56205 changed lines
> X-Y, Z of file fs/ext2/super.c" but doesn't actually contain those
> changes, so that the CSET dependency graph is still kept intact.
In other words, "proxy" == "place holder". This is doable but it makes
synchronizing repositories quite a bit more complex. I.e., if I pull
from you and I have place holders and you have the real thing, should
I get 'em or not? If the answer is always "or not", then this is a
doable thing. We'd need to modify the "bk takepatch" code path to do
the right thing when given the real patch but that's doable as well.
Interesting idea, we could do this and it would be relatively fast to
do, like a week or two.
> It would also lose the BK CSET identification, which would tell the
> original submitter (and his local repository) that the patch was applied,
We wouldn't lose it, we'd have to add some extra state to say it is in there
but only as a placeholder, so keep bugging Linus.
----- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/