[lkml]   [2002]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Changelogs on
On Wed, 2002-05-15 at 22:15, David Woodhouse wrote:
> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:26    [W:0.072 / U:0.400 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site