|
From: | Hugh Sasse |
Subject: | Re: A less invasive rcs |
Date: | Mon, 15 Feb 2021 12:09:14 +0000 |
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
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 <john@yates-sheets.org>
Sent: 15 February 2021 11:19 To: Hugh Sasse <hgs@dmu.ac.uk> Cc: help-rcs@gnu.org <help-rcs@gnu.org> Subject: Re: A less invasive rcs
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 <hgs@dmu.ac.uk> wrote:
John Yates
505 Tremont St, #803
Boston, MA 02116
|
[Prev in Thread] | Current Thread | [Next in Thread] |