CVS repository rsync

Started by Magnus Haganderabout 19 years ago5 messages
#1Magnus Hagander
mha@sollentuna.net

I've set up my laptop to sync down the full cvs repository using rsync
(remember - windows = no cvsup). This works well, except every now and
then (not every time, but definitly often enough to bother me) it
resyncs the entire repository, and not just the files that have had
commits to them.

Anybody have a clue as to why this is happening, and what I can do about
it?

//Magnus

#2Neil Conway
neilc@samurai.com
In reply to: Magnus Hagander (#1)
Re: CVS repository rsync

On Thu, 2006-10-19 at 19:52 +0200, Magnus Hagander wrote:

I've set up my laptop to sync down the full cvs repository using rsync
(remember - windows = no cvsup).

Yeah, I do this as well, and for similar reasons (cvsup is unmaintained
and annoying to build, at least on AMD64/Debian).

This works well, except every now and
then (not every time, but definitly often enough to bother me) it
resyncs the entire repository, and not just the files that have had
commits to them.

I haven't noticed this personally, although I might have just missed it.
Are you sure you're not just noticing the times when a new release has
been tagged? (Tagging in CVS requires touching all tagged files.)

-Neil

#3Magnus Hagander
mha@sollentuna.net
In reply to: Neil Conway (#2)
Re: CVS repository rsync

This works well, except every now and
then (not every time, but definitly often enough to bother me) it
resyncs the entire repository, and not just the files that have had
commits to them.

I haven't noticed this personally, although I might have just
missed it.
Are you sure you're not just noticing the times when a new
release has been tagged? (Tagging in CVS requires touching
all tagged files.)

Hmm, now that you mention it, at least this time that's probably the
reason. Didn't consider that a tag in a *backbranch* affects all the
files inthe repository for HEAD as well. I guess I'll just keep my eyes
open for next time it happens to see if that happens then as well.

//Magnus

#4Steve Crawford
scrawford@pinpointresearch.com
In reply to: Magnus Hagander (#1)
Re: CVS repository rsync

Magnus Hagander wrote:

I've set up my laptop to sync down the full cvs repository using rsync
(remember - windows = no cvsup). This works well, except every now and
then (not every time, but definitly often enough to bother me) it
resyncs the entire repository, and not just the files that have had
commits to them.

Anybody have a clue as to why this is happening, and what I can do about
it?

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

This, perhaps?:

--modify-window
When comparing two timestamps rsync treats the timestamps as
being equal if they are within the value of modify_window. This
is normally zero, but you may find it useful to set this to a
larger value in some situations. In particular, when transfer-
ring to Windows FAT filesystems which cannot represent times
with a 1 second resolution --modify-window=1 is useful.

(from rsync man page)

Cheers,
Steve

#5Magnus Hagander
mha@sollentuna.net
In reply to: Steve Crawford (#4)
Re: CVS repository rsync

I've set up my laptop to sync down the full cvs repository

using rsync

(remember - windows = no cvsup). This works well, except

every now and

then (not every time, but definitly often enough to bother me) it
resyncs the entire repository, and not just the files that have had
commits to them.

Anybody have a clue as to why this is happening, and what I can do
about it?

This, perhaps?:

--modify-window
When comparing two timestamps rsync treats the timestamps as
being equal if they are within the value of modify_window. This
is normally zero, but you may find it useful to set this to a
larger value in some situations. In particular, when transfer-
ring to Windows FAT filesystems which cannot represent times
with a 1 second resolution --modify-window=1 is useful.

(from rsync man page)

Maybe. But I'm on NTFS, which has 100-naonsecond granularity on times,
so it's much more exact than the server ;-)

//Magnus