Re: Changelogs on kernel.org

[Kenneth Johansson <ken@canit.se>]

On Wed, 2002-05-15 at 22:15, David Woodhouse wrote:
> 
> lm@bitmover.com said:
> > It's probably best if you simply view this as a BK limitation which
> > isn't going away any time soon and don't put junk changesets in the
> > middle of your stream of changes.  It's easy enough to export the
> > change you want as a patch, export the comments in the form that bk
> > comments wants, undo the junk changeset, import the patch, and set the
> > comments.  Yeah, it's awkward; consider that a feedback loop which
> > encourages you to think a bit more about what you put in the tree.
> 
> What it actually encourages is for people to have multiple throwaway trees. 
> (Which isn't quite so much of a BK turnoff once you discover compilercache.)
> 
> If the tree's going to be thrown away anyway, it doesn't matter if it gets 
> confused -- how about making it a little easier to backport changesets -- 
> surely it should be possible to make BK import a changeset iff all the 
> affected files are identical in both trees before the changeset? 

while we are adding to the wishlist here is a few more items.

Away to make a clone with all files checked out in edit mode. I find
that I always do the checkout anyway and maybe it's possible to make it
faster if it's done at clone time.

Also I have found that it is a pain in the a** to have debug code that I
really don't want to save but it's temporary usefull. When I do a pull
that changes the same file the pull don't work and I have to unedit the
file and lose the debug code or make a needless checkin. I would really
like if it was possible to do a merge that is only in the checkedout
file not stored as a changeset.