public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeffrey A Law <law@cygnus.com>
To: Craig Burley <burley@gnu.org>
Cc: oliva@dcc.unicamp.br, pfeifer@dbai.tuwien.ac.at, egcs@cygnus.com
Subject: Re: Inconsistance in snapshots repository
Date: Thu, 16 Apr 1998 23:59:00 -0000	[thread overview]
Message-ID: <6435.892776422@hurl.cygnus.com> (raw)
In-Reply-To: <199804162331.TAA25018@melange.gnu.org>

  In message < 199804162331.TAA25018@melange.gnu.org >you write:
  > I'm CVS-unaware, but, generally, is this really guaranteed to provide
  > a coherent snapshot to anyone, anytime, including if they try using
  > it while a snapshot is being produced (and the "moving tag" updated)?
Nope.  But what it does do for the CVS folks is allow them to 
upgrade to whatever the current snapshot happens to be without
knowing the exact name of the tag.  I think that was the idea
behind the suggestion.  The tag doesn't move until I make the
snapshot available.

And the window where things can get out of sync is relatively small;
directories are locked as the tag is added/moved.

[ I'm not a CVS expert - there may or may not be things in CVS to
  prevent the following "problems". ]

To get an out of sync tree you'd have to start after the tag process
and somehow get ahead of the tag process (might be able to happen if
for example you don't have some subdirs and can "leap frog" over
the tag process while the tag process walks through the subdirs.

Another possibility would be an update starting after tagging, then
both the update & tag block waiting on the same lock.  The updater
might be able to get the lock before the tagger and get an inconsistent
tree.

The opposite of those cases might be able to happen too.

In both situations another cvs update ought to fix any
inconsistencies.


I don't consider these serious prolems (if they exist at all), but
others may disagree.

jeff

  parent reply	other threads:[~1998-04-16 23:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-04-14  9:37 Gabriel Dos Reis
1998-04-14 13:21 ` Jeffrey A Law
1998-04-14 15:23 ` Gerald Pfeifer
1998-04-14 21:01   ` Alexandre Oliva
1998-04-15 15:09     ` Jeffrey A Law
1998-04-15 23:03       ` Raja R Harinath
1998-04-16 10:35         ` Jeffrey A Law
1998-04-16 23:59       ` Craig Burley
1998-04-16 23:59         ` Alexandre Oliva
1998-04-16 18:39           ` Craig Burley
1998-04-16 18:39             ` Jeffrey A Law
1998-04-16 23:59         ` Jeffrey A Law [this message]
1998-04-17 14:42           ` Joe Buck
1998-04-17 23:53             ` Jeffrey A Law
1998-04-14 23:16   ` Jeffrey A Law
1998-04-23 13:31     ` Gerald Pfeifer
1998-05-24  2:32       ` Jeffrey A Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6435.892776422@hurl.cygnus.com \
    --to=law@cygnus.com \
    --cc=burley@gnu.org \
    --cc=egcs@cygnus.com \
    --cc=oliva@dcc.unicamp.br \
    --cc=pfeifer@dbai.tuwien.ac.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).