Re: [Gnu-arch-users] cscvs cache -u while others are commiting large changesets in CVS

[Robert Collins]

On Tue, 2004-05-04 at 08:15, Charles Duffy wrote:
> On Mon, 2004-05-03 at 16:48, Robert Collins wrote:
> > What should happen is that
> > the next cache run will have an additional changeset with the later
> > portion of that developers changes.
> 
> Robert,
> 
> I don't like defining that as correct behaviour, because it means that
> running "cscvs cache -b" can result in different changeset numbers than
> repeated runs of "cscvs cache -u".
> 
> Granted, the current behaviour isn't exactly ideal either for the
> reasons raised in this thread.

Yeah, it's tricky.

What about this then. Store the maximum time delta in the catalog. Once
set, it's immutable. When adding to a changeset, do not permit adding to
ones in the Catalog, but check and raise an exception should one attempt
to add to one present in the catalog from before this run.

(Checking the date of now against the rlog date and not adding the
changeset if it's within the max time delta isn't robust: you don't want
to know how many incorrect-dates I've seen on CVS servers).

Now, we could also add don't-add-changeset-within-the max time
delta-from-now as a additional guard...

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part