Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)

[Andrea Arcangeli <andrea@suse.de>]

Hi,

On Mon, Jul 21, 2003 at 06:00:00PM -0400, Andrea Arcangeli wrote:
> On Mon, Jul 21, 2003 at 02:31:59PM -0700, Larry McVoy wrote:
> > On Mon, Jul 21, 2003 at 05:21:55PM -0400, Andrea Arcangeli wrote:
> > > Hi Larry,
> > > 
> > > On Mon, Jul 21, 2003 at 12:45:14PM -0700, Larry McVoy wrote:
> > > > You don't need the tags, use dates.  You can get the date range you want 
> > > > with an rlog of the ChangeSet file and then use those dates.
> > > 
> > > I realized I could do this, and it can of course be automated with an
> > > additional bkcvs specific hack in cvsps. But the tag in every file would
> > > have kept the functionality generic with the already available -r
> > > option, and since I can't see any downside in the tag in the files, I
> > > prefer that generic way.
> > 
> > The tags means that each file gets modified for each tag and then we have
> > to transfer the whole tree after a tag.  It thrashes the hell out of the
> > disk too, for no good reason.
> > 
> > Also note that there are nowhere near as many tags as there are commits
> > in the CVS tree.  So by using tags you are restricting yourself to coarse
> > granularity in your bug hunts.
> 
> the granularity wasn't the issue, I need this feature anyways out of
> cvsps (cvsps is exactly the thing that generates the changesets out of
> the coarse granularity of the tags). the checkout/rsync being more
> expensive sounds a fair enough argument for implementing the feature in
> cvsps where it will be zero write cost.

while writing the code to do it, I noticed the heuristic was already
there in cvsps ;), and it is generic (not hardwired to the ChangeSet
file). I had bad luck diffing with -r v2_4_22-pre3 (which is missing
from the changeset file too, so I guess the info is missing in bitkeeper
as well, not just bkcvs).  Infact probably it's a long time that you
dropped the tags from all files, and I noticed only now after getting
the error diffing against 22pre3 ;).

> since we're talking about bkcvs, I also would have a feature wish for
> the repository export in rsync.kernel.org: would it be possible to
> export a sequence number increased once before a transfer, and increased
> a second time after the tree is coherent again? When the sequence number
> is even and it didn't change before and after the rsync, we'll know the
> current status is coherent and we don't need to repeat the rsync (after
> some delay). Or is there any other mechanism that guarantees to get a
> coherent repository out of rsync?

Peter, any suggestion on this? Larry said it's all on your side, so I
assume you're running bkcvs yourself, or Larry is already providing you
a locking mechanism that serializes against bkcvs and that allows you
to fetch a coherent of the cvs repository. w/o this last locking bit
that allows to export a coherent copy of the repository, I can't easily
automate the stuff based on a local repository and I've to switch to the
remote one, despite having it local is more flexible (and much faster
for local browsing) and rsync -z is faster.

Many thanks again to both of you and last but not the least to David
Mansfiel (cvsps author).

Andrea