I've never worked with Perforce and have heard good and bad things about the
commercial offerings. Wiping the disk rather than just adding what needs to be
added seems rather drastic!
I don't, even now, fully understand what git does with nested repositories, not
being too keen to repeat the experience. To borrow your ASCII art, I'm
thinking about this:
.../project
├── src
│ ├── foo.c
│ ├── bar.c
│ └── /nested
│ ├── src
│ │ ├── baz.c
│ │ └── qux.c
│ ├── inc
│ │ ├── baz.h
│ │ └── qux.h
│ ├── doc
│ │ └── baz.md
│ └── .rcs
│ ├── src
│ │ ├── baz.c,v
│ │ └── qux.c,v
│ ├── inc
│ │ ├── baz.h,v
│ │ └── qux.h,v
│ └── doc
│ └── baz.md,v
├── inc
│ ├── foo.h
│ └── bar.h
├── doc
│ └── foo.md
└── .rcs
├── src
│ ├── foo.c,v
│ └── bar.c,v
├── inc
│ ├── foo.h,v
│ └── bar.h,v
└── doc
└── foo.md,v
When you try to rcs commit .../project, and it hits the newly created
src/nested/, then, I think it should, or maybe RFC style: MUST, backup the
contained RCS directories, because it is not playing the role of looking of RCS
data at this point, it is looking for files to squirrel away. Git would, I
think, just stop, and ignore them, or bark at the user.
This would probably result in things like qux.c,v,v in the RCS folder, but I
think that could be lived with.
However, this is only my expectation, at the moment. I don't know if I am
right. There may be a better way that makes more sense, and once I see it, I
will think, "Oh, of course, that is obvious!!"
Working inside nested/ should work as you suggest. (It is the same structure;
I just changed the names.)
Does this show you what I'm talking about?
Thank you,
Hugh
________________________________
From: John Yates <[email protected]>
Sent: 15 February 2021 11:19
To: Hugh Sasse <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: A less invasive rcs
This message was sent from outside of DMU. Please do not click links or open
attachments unless you recognise the source of this email and know the content
is safe.
Hi Hugh,
I can empathize with your memory of a bad experience.
My motivation for this project is a bad experience with git
in which unsaved (not yet added) files got lost via a hard
reset. As an emacs user I want a mechanism that will
preserve my changes on every save. Furthermore, I want
those changes saved outside of my project tree. (At work
that project tree gets wiped out and recreated by our crazy
Perforce integration.)
A related project is to add a vc-timemachine capability,
modeled on git-timemachine. This is why I want my
changes saved in rcs instead of as a collection of date-
time suffixed files (á la today's backup-each-save.el).
I would like to better understand your suggestion for how
to handle nested trees. Over the years git has had many
runs at the problem of nested projects and all have been
quite complex. My hope is that rcs's file-centric simplicity
will save us.
/john
On Mon, Feb 15, 2021 at 5:55 AM Hugh Sasse
<[email protected]<mailto:[email protected]>> wrote:
I like the simplicity and clarity of RCS in comparison with git. (The other
features of git are often appropriate.) I see the benefits of having a
separate tree and note the idea of having a top marker. However, I had a
horrible experience when I created a git repository which I hadn't remembered
was in a directory already in one. When I went to the top, the enclosing git
functionality just failed on me, and I can't remember the failure message now
(it's about ten years). I thought I was going to lose my research. This was
too close to a deadline to be fun.
I think the design of the interface for when things get nested, even
accidentally, will need to be thought through very carefully. My expectations
of "It should just work" were that the current state of the enclosed repository
should be saved when the outer one was saved. [I had added all.] After all,
it is just a collection of files within the structure that happen to contain a
.git directory, etc.
There may be a whole load of expectations from people, all very different, but
my feeling was "A version control system may not injure a user's files, or,
through inaction, allow them to come to harm" :-)! It took me too long to work
out what had happened, and didn't do me much good, never mind my files! The
computer has access to all this information, so it should be able to remind the
overburdened user that there is an enclosed repository, not the other way round.
I suspect the "Human Factors" of this may be more difficult than I imagine.
Thank you,
Hugh
________________________________
From: help-rcs
<[email protected]<mailto:[email protected]>> on behalf of
John Yates <[email protected]<mailto:[email protected]>>
Sent: 14 February 2021 02:38
To: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: A less invasive rcs
This message was sent from outside of DMU. Please do not click links or open
attachments unless you recognise the source of this email and know the content
is safe.
I am brainstorming some extensions to rcs that would
* Avoid both ,v files and RCS directories in working trees
* Allow the ,v files to be stored in a fully separate tree
Today, we have two places for a working file's ,v file:
* In the working file's working directory
* In an RCS subdirectory added to that working directory
I propose a third location, a mirror of that working directory
located by searching upward, through parent directories, for
a "dominating" .rcs directory. If such a directory is found, it
contains a parallel directory structure:
.../project
├── src
│ ├── foo.c
│ └── bar.c
├── inc
│ ├── foo.h
│ └── bar.h
├── doc
│ └── foo.md
└── .rcs
├── src
│ ├── foo.c,v
│ └── bar.c,v
├── inc
│ ├── foo.h,v
│ └── bar.h,v
└── doc
└── foo.md,v
How to search for a ,v file:
* Look in working file's directory
* If the working directory contains an RCS sub-directory,
then look there
* If a "dominating" .rcs directory exists, look in the
corresponding directory
Where to create a new ,v file:
* If a "dominating" .rcs directory exists, ensure existence
of a corresponding directory and create it there
* If a RCS sub-directory exists, create it there
* Create it in the working file's working directory
To provide a means of stopping the upward search for a .rcs
marker I propose a very simple .rcsstop marker.
At this point I take some inspiration from git for a separate
directory convention. This means allowing the "dominating"
.rcs marker to be a file, similar to .git. If it is a file then it is
a "file system agnostic" symbolic link to an out of tree .rcs
directory. The contents of this file is
rcsdir: <path>
Does this seem too crazy? Any implementation suggestions?
Where is the relevant search logic implemented in the rcs
source?
/john
--
John Yates
505 Tremont St, #803
Boston, MA 02116
