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/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:39 EST