Обсуждение: CVS repository rsync

Поиск
Список
Период
Сортировка

CVS repository rsync

От
"Magnus Hagander"
Дата:
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



Re: CVS repository rsync

От
Neil Conway
Дата:
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




Re: CVS repository rsync

От
"Magnus Hagander"
Дата:
> > 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


Re: CVS repository rsync

От
Steve Crawford
Дата:
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
valueof 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
secondresolution --modify-window=1 is useful. 

(from rsync man page)

Cheers,
Steve



Re: CVS repository rsync

От
"Magnus Hagander"
Дата:
> > 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