Re: Changelogs on kernel.org

Kenneth Johansson (ken@canit.se)
15 May 2002 23:03:34 +0200


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.


-
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/