[9fans] pull - read this!

[9fans] pull - read this!

[Russ Cox]

THE OPTIONS TO PULL HAVE CHANGED - READ THIS MESSAGE!

I don't have the energy to explain the antiword behavior in full,
but I just made some changes that should make it less
likely going forward.

I changed the way -c and -s work in pull (which is really
replica/applylog for the purposes of this discussion).

Before, the only way to safely make pull remember that
it had done some -c stuff was to run replica/pull -vc
with no patterns and hope that no new server changes
had appeared since the last pull you did (usually seconds
before).  I made pull a little more aggressive about updating
its "I'm done with the log up to this point" time, but if
you get really far behind and are trying to catch up, it's
just not good enough.

Instead, I changed -c and -s.

Now, instead of -c and -s applying to all possible files
encountered, they take names as arguments and only
apply to those.  This means you can specify both on
a command line.

So for example, I just updated my own system:

	% pull
	sys/src/cmd/8c/txt.c: locally modified; will not update
	sys/src/cmd/venti/config.c: locally removed; will not update
	sys/src/cmd/venti/fmtindex.c: locally removed; will not update
	386/bin/replica/applylog: locally modified; will not update
	sys/src/cmd/replica/applylog.c: locally modified; will not update
	%

and then had to address the conflicts.  I wanted to keep
my venti changes but the others could be overwritten:

	% pull -c sys/src/cmd/venti -c 386/bin/replica \
		-c sys/src/cmd/replica -s sys/src/cmd/8c
	% pull
	c sys/src/cmd/8c/txt.c
	%

Because the options changed to take arguments, I had
to update /usr/glenda/bin/rc/pull and /rc/bin/replica/defs too.

If you have your own copy of glenda's pull script, 
you'll want to incorporate the changes.  Or just make
yours run hers:

	% cat /usr/rsc/bin/rc/pull
	#!/bin/rc
	exec /usr/glenda/bin/rc/pull $*
	% 

The man pages are updated too.

All this won't take effect until you do a pull and get the new files.

Russ

Re: [9fans] pull - read this!

[Russ Cox]

> 	% pull -c sys/src/cmd/venti -c 386/bin/replica \
> 		-c sys/src/cmd/replica -s sys/src/cmd/8c
> **	% pull
> 	c sys/src/cmd/8c/txt.c
> 	%

Pretend the starred line isn't there.

Russ

Re: [9fans] pull

[Heiko Dudzus]

Russ Cox wrote:
> I changed the way -c and -s work in pull

I have a strange thing with the new pull:

| # replica/pull -v -c 386/9pcf /dist/replica/network 386/9pcf
| stopped updating log apply time because of 386/bin/mkstate
| #

But 386/bin/mkstate neither exists on sources nor on the local
filesystem.

What's going on there?

Heiko

Re: [9fans] pull

[Russ Cox]

> Russ Cox wrote:
> > I changed the way -c and -s work in pull
> 
> I have a strange thing with the new pull:
> 
> | # replica/pull -v -c 386/9pcf /dist/replica/network 386/9pcf
> | stopped updating log apply time because of 386/bin/mkstate
> | #
> 
> But 386/bin/mkstate neither exists on sources nor on the local
> filesystem.
> 
> What's going on there?

You can ignore this message if you want, but I print it to make
you wonder what's going on.  In this case, you should probably
be running

	replica/pull -v -c 386/9pcf /dist/replica/network

which will pull any files except skip past changes to 386/9pcf.

What you typed:

	replica/pull -v -c 386/9pcf /dist/replica/network 386/9pcf

will not pull any changes.  It says "pull only files matching 386/9pcf
(the last argument) but whenever you see a change to 386/9pcf,
ignoring it in favor of the local version (the -c option)."  

At any point in time, replica/pull knows how much of
/dist/replica/client/plan9.log it has successfully applied and
can ignore on the next run.  It stores this information in
/dist/replica/client/plan9.time.  Plan9.log is applied up to and
including the line that begins with the numbers in plan9.time.

If replica/pull reads through the log but cannot update
plan9.time to mark that it has been through that part, 
then it prints something to tell you why.  In this case,
the part of the log yet to be applied mentions 386/bin/mkstate,
and you've instructed replica/pull only to pay attention to
log lines mentioning 386/9pcf, so it will not change plan9.time
to say that the log is fully applied (it's not!).

I'm sorry this is so confusing.  I don't have a better way
to explain it.  The new -s and -c options make things
so that you should never need to put arguments after
/dist/replica/network on a pull command line.

Russ