Re: [9fans] lucio-

Re: [9fans] lucio-

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

> No offense meant, but doesn't this show precisely what CVS's strength
> is?  Had you recorded the fix, we wouldn't be still looking for it :-)

It shows that I should keep better
records of what I do each day.

Even if I had the CVS source under
CVS, I probably would have thrown out
the repository when I ported the new one.
Further, I'm not sure whether the bug was
in CVS or in APE.

If I remembered what was broken,
I could run history to find it.

Case in point: I just found it, by
poking around for files in /sys/src/ape
modified about the same date as when I
ported the new CVS (which I remember being
near when I found the bug).

CVS wouldn't have helped any more than the
dump here.

The bug is in /sys/src/ape/lib/ap/plan9/getcwd.c.
Replace the entire file with:

#include "lib.h"
#include <stddef.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <stdio.h>
#include "sys9.h"
#include "dir.h"

char*
getcwd(char *buf, size_t len)
{
	int fd;

	fd = _OPEN(".", OREAD);
	if(fd < 0) {
		errno = EACCES;
		return 0;
	}
	if(_FD2PATH(fd, buf, len) < 0) {
		errno = EIO;
		_CLOSE(fd);
		return 0;
	}
	_CLOSE(fd);

	return buf;
}

Exercise to the reader: find the fd leak in the
original.

Russ

[-- Attachment #2: Type: message/rfc822, Size: 2436 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] lucio-
Date: Wed, 9 Jan 2002 06:52:59 +0200
Message-ID: <20020109065259.G12098@cackle.proxima.alt.za>

On Tue, Jan 08, 2002 at 10:06:45PM -0500, Russ Cox wrote:
>
> For the list, I've fixed this bug before.
> I remember it being a neat bug, but I don't
> remember what it was.  Once Lucio and I figure
> it out again, one of us will post what the
> problem was.  Perhaps it was cvs, perhaps APE,
> perhaps some weird interaction between the
> two.  I've been trying to remember all day.
>
No offense meant, but doesn't this show precisely what CVS's strength
is?  Had you recorded the fix, we wouldn't be still looking for it :-)

But I agree wholeheartedly that CVS is only a partial solution and
that the needs it attempts to address vary widely.  I'm tempted to
create a mailing list specially to discuss a CVS-like development
that merges the Plan 9 backup technology into it.  Any takers?

++L

Re: [9fans] lucio-

[Lucio De Re]

On Wed, Jan 09, 2002 at 12:08:04AM -0500, Russ Cox wrote:
>
> > No offense meant, but doesn't this show precisely what CVS's strength
> > is?  Had you recorded the fix, we wouldn't be still looking for it :-)
>
> It shows that I should keep better
> records of what I do each day.
>
Which dump does wonderfully on your behalf.  I confess to a similar
difficulty with tracking my activities.  Hm.  Old Univac Exec-8
had some form of file versioning that might also be worth knowing
about.  The editors were aware of it, but it was at filesystem
level, in some fashion quite different from what is conventional
today.

> Even if I had the CVS source under
> CVS, I probably would have thrown out
> the repository when I ported the new one.
> Further, I'm not sure whether the bug was
> in CVS or in APE.
>
Well, maybe.  A remote repository (in my opinion, this is CVS's
biggest improvement on RCS, but consensus lies elsewhere :-) would
have been harder to clobber.  Still, a broken APE library would be
hard to identify from changes (or lack of changes - that would be
at least an indication) to a CVS repository.

> CVS wouldn't have helped any more than the
> dump here.
>
I am suitably chastised :-)

> The bug is in /sys/src/ape/lib/ap/plan9/getcwd.c.
> Replace the entire file with:
>
Thank you for finding this.  I had just started to follow your
instructions, but got tangled up in my very limited understanding
of acid (I am debugger-shy at best, ACID looks wonderful, but hard
to wrap one's old-fashioned mind around).

> Exercise to the reader: find the fd leak in the
> original.
>
You must be joking, right?  There's no relationship between the
original and the version you provided :-)  Well, nearly no
relationship.  I wondered about the "entire file" when I first read
it.  I hope _never_ to have to find out what the "newkernel" stuff
and its ilk were intended for.

++L

Re: [9fans] lucio-

[Lucio De Re]

On Wed, Jan 09, 2002 at 07:32:51AM +0200, Lucio De Re wrote:
>
> > The bug is in /sys/src/ape/lib/ap/plan9/getcwd.c.
> > Replace the entire file with:
> >
> Thank you for finding this.  I had just started to follow your
> instructions, but got tangled up in my very limited understanding
> of acid (I am debugger-shy at best, ACID looks wonderful, but hard
> to wrap one's old-fashioned mind around).
>
The reason Russ's instructions were beyond my ability to follow is
that I had stripped the executable :-(

Now to get the APE lib to behave itself...

++L

Re: [9fans] lucio-

[Bruce Janson]

In article <20020109073250.H12098@cackle.proxima.alt.za>,
Lucio De Re <9fans@cse.psu.edu> wrote:
...
>Which dump does wonderfully on your behalf.  I confess to a similar
...

dump wins out over the SCCS/RCS/CVS per-application approaches by
including more of the environment: e.g. compiler, system includes.
(In practice, has this been a significant win at the Labs?)

Two of the limitations of dump are its coarse granularity and its
arbitrary timing.  To eliminate these one could extend dump by
allowing anybody to force (and annotate) a dump snapshot.

Source version control (Was: [9fans] lucio-)

[Lucio De Re]

On Thu, Jan 10, 2002 at 10:37:55AM +0000, Bruce Janson wrote:
>
> dump wins out over the SCCS/RCS/CVS per-application approaches by
> including more of the environment: e.g. compiler, system includes.
> (In practice, has this been a significant win at the Labs?)
>
They address two different problem spaces, with solutions appropriate
to each.  That's my issue all along: is there a generic approach
that will satisfy a majority of version control needs, or do there
have to be mutually exclusive solutions for a wide range of project
types?

> Two of the limitations of dump are its coarse granularity and its
> arbitrary timing.  To eliminate these one could extend dump by
> allowing anybody to force (and annotate) a dump snapshot.

I hesitate to call the timing arbitrary or, for that matter, coarse,
because it reminds me of arguments about the real time nature of
computer response: throw enough power at it and you can approximate
the ideal as closely as you like.  Which in itself raises some
interesting considerations.

But the automatic nature has both benefits and disadvantages: on
the one hand it guarantees that history is retained and on the
other it allows the user to abrogate all responsibility for doing
so.

The real downside is that annotation, which, as mentioned here in
connection with the changelog, is extremely useful, becomes an even
greater burden for programmers, who are already notorious for
disliking the generation of documentation.

Naturally, the picture painted above is simplistic, but it covers
the most pertinent issues of source control: the retention of as
much information as possible.  In this category we can also include
the labelling of releases and, without the doubt, details of the
broader environment in which the change occurred.

A last note about the environment, while I think about it: /n/dump
provides a pretty good boundary, but certainly too wide to be
practical for a distributed programming project (think Linux).  In
CVS, the boundary may well be too tight (yesterday's problem with
CVS and APE is a case in point).  At the very minimum, there may
be a need to provide a boundary that is more relaxed than the CVS
"working directory", alternatively software developers may have to
be able to include in the concept of a "workspace" any modules
outside of the working directory that have been altered during
development and at the very least annotate the history accordingly.
The option to provide local copies of the environment with each
and every working directory is just too impractical, if not downright
insane (yet, ghostscript, ssh and others all include a copy of zlib
sources in the source distribution archives).

++L

Re: [9fans] lucio-

[Richard Uhtenwoldt]

I'm responding to an old message.

on Jan 10, Bruce Janson wrote:

>Two of the limitations of dump are its coarse granularity and its
>arbitrary timing.  To eliminate these one could extend dump by
>allowing anybody to force (and annotate) a dump snapshot.

I believe that the current implementation of dump snapshotting
bogs down the fileserver so it would be annoying to run it
when people are doing work and that is why dump snapshotting
runs in the wee hours at Bell Labs.

(Of course, it could be redone if that was deemed valuable.)

Re: Source version control (Was: [9fans] lucio-)

[Fco.J.Ballesteros]

Why don't you just change the implementation of the file server
to accept a remote 'dump name' command to cause an immediate dump at root
/n/dump/name/ ?
Of course this would need to implement something like a /ctl file
on the file server to accept innocent-looking(?) commands from other machines.