|
From: | Hugh Sasse |
Subject: | Re: A less invasive rcs |
Date: | Mon, 15 Feb 2021 10:55:19 +0000 |
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 <help-rcs-bounces+hgs=dmu.ac.uk@gnu.org> on behalf of John Yates <john@yates-sheets.org>
Sent: 14 February 2021 02:38 To: help-rcs@gnu.org <help-rcs@gnu.org> Subject: A less invasive rcs
I am brainstorming some extensions to rcs that would
Today, we have two places for a working file's ,v file:
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:
Where to create a new ,v file:
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
|
[Prev in Thread] | Current Thread | [Next in Thread] |