Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 29 Jul 2003 11:28:21 +0200 | From | Andrea Arcangeli <> | Subject | Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd) |
| |
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 - 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/
| ![\](/images/icornerr.gif) |