Re: A less invasive rcs
Hugh Sasse <[email protected]> Mon, 15 Feb 2021 10:55:19 +0000
| Newsgroups | gmane.comp.gnu.rcs |
|---|---|
| Message-ID | <AM6PR0302MB31898553DCED782B5E2E0D86E6889@AM6PR0302MB3189.eurprd03.prod.outlook.com> |
--_000_AM6PR0302MB31898553DCED782B5E2E0D86E6889AM6PR0302MB3189_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable I like the simplicity and clarity of RCS in comparison with git. (The othe= r features of git are often appropriate.) I see the benefits of having a s= eparate tree and note the idea of having a top marker. However, I had a ho= rrible 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 messa= ge 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 accide= ntally, will need to be thought through very carefully. My expectations o= f "It should just work" were that the current state of the enclosed reposit= ory should be saved when the outer one was saved. [I had added all.] Afte= r 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 lon= g 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 ab= le to remind the overburdened user that there is an enclosed repository, no= t 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]> on behalf of John= Yates <[email protected]> Sent: 14 February 2021 02:38 To: [email protected] <[email protected]> Subject: A less invasive rcs This message was sent from outside of DMU. Please do not click links or ope= n attachments unless you recognise the source of this email and know the co= ntent 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 =86=80=80 src =81 =86=80=80 foo.c =81 =84=80=80 bar.c =86=80=80 inc =81 =86=80=80 foo.h =81 =84=80=80 bar.h =86=80=80 doc =81 =84=80=80 foo.md =84=80=80 .rcs =86=80=80 src =81 =86=80=80 foo.c,v =81 =84=80=80 bar.c,v =86=80=80 inc =81 =86=80=80 foo.h,v =81 =84=80=80 bar.h,v =84=80=80 doc =84=80=80 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 --_000_AM6PR0302MB31898553DCED782B5E2E0D86E6889AM6PR0302MB3189_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dkoi8-r"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> 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. Howe= ver, I had a horrible experience when I created a git repository which I hadn't remembered was in a directory already in o= ne. When I went to the top, the enclosing git functionality just fail= ed on me, and I can't remember the failure message now (it's about ten year= s). I thought I was going to lose my research. This was too close to a deadline to be fun.</div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> I think the design of the interface for when things get nested, even accide= ntally, will need to be thought through very carefully. My expe= ctations 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 coll= ection of files within the structure that happen to contain a .git director= y, etc. </div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> 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 f= iles, 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 ac= cess to all this information, so it should be able to remind the overburden= ed user that there is an enclosed repository, not the other way round.</div= > <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> I suspect the "Human Factors" of this may be more difficult than = I imagine.</div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> Thank you,</div> <div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size= : 12pt; color: rgb(0, 0, 0);"> Hugh</div> <div id=3D"appendonsend"></div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> help-rcs <help-rcs= [email protected]> on behalf of John Yates <john@yates= -sheets.org><br> <b>Sent:</b> 14 February 2021 02:38<br> <b>To:</b> [email protected] <[email protected]><br> <b>Subject:</b> A less invasive rcs</font> <div> </div> </div> <div> <table> <tbody> <tr> <td bgcolor=3D"#ffffff"><font color=3D"#000000"> <pre>This message was sent from outside of DMU. Please do not click links o= r open attachments unless you recognise the source of this email and know t= he content is safe.</pre> </font></td> </tr> </tbody> </table> <div dir=3D"ltr"> <div class=3D"x_gmail_default" style=3D"font-family:arial,helvetica,sans-se= rif">I am brainstorming some extensions to rcs that would</div> <div class=3D"x_gmail_default" style=3D""> <ul style=3D"font-family:arial,helvetica,sans-serif"> <li>Avoid both ,v files and RCS directories in working trees</li><li>Allow = the ,v files to be stored in a fully separate tree</li></ul> <div style=3D"font-family:arial,helvetica,sans-serif">Today, we have two pl= aces for a working file's ,v file:</div> <div style=3D"font-family:arial,helvetica,sans-serif"> <ul> <li>In the working file's working directory</li><li>In an RCS subdirectory = added to that working directory</li></ul> <div>I propose a third location, a mirror of that working directo= ry<br> located by searching upward, through parent directories, for<br> a "dominating" .rcs directory. If such a directory is found= , it<br> contains a parallel directory structure:</div> </div> <div style=3D"font-family:arial,helvetica,sans-serif"><br> </div> <div style=3D""><font face=3D"monospace"> .../project<br> =86=80=80 src<br> =81 =86=80=80 foo.c<br> =81 =84=80=80 bar.c<br> =86=80=80 inc<br> =81 =86=80=80 foo.h<br> =81 =84=80=80 bar.h<br> =86=80=80 doc<br> =81 =84=80=80 foo.md<br> =84=80=80 .rcs<br> =86=80=80 src<br> =81 =86=80=80 foo.c,v<br> =81 =84=80=80 bar.c,v<br> =86=80=80 inc<br> =81 =86=80=80 foo.h,v<br> =81 =84=80=80 bar.h,v<br> =84=80=80 doc<br> =84=80=80 foo.md,v<= br> </font></div> <div style=3D"font-family:arial,helvetica,sans-serif"><br> </div> <div style=3D"font-family:arial,helvetica,sans-serif">How to search for a ,= v file:</div> <div style=3D"font-family:arial,helvetica,sans-serif"> <ul> <li>Look in working file's directory</li><li>If the working directory conta= ins an RCS sub-directory,<br> then look there</li><li>If a "dominating" .rcs directory exists, = look in the<br> corresponding directory</li></ul> <div>Where to create a new ,v file:</div> <div> <ul> <li>If a "dominating" .rcs directory exists, ensure existence<br> of a corresponding directory and create it there</li><li>If a RCS sub-direc= tory exists, create it there</li><li>Create it in the working file's workin= g directory</li></ul> </div> </div> <div style=3D"font-family:arial,helvetica,sans-serif"> <div> <div class=3D"x_gmail_default">To provide a means of stopping the upward se= arch for a .rcs<br> marker I propose a very simple .rcsstop marker.</div> </div> <div class=3D"x_gmail_default"><br> </div> <div class=3D"x_gmail_default"></div> </div> <div style=3D"font-family:arial,helvetica,sans-serif">At this point I take = some inspiration from git for a separate</div> <div style=3D"font-family:arial,helvetica,sans-serif">directory convention.= This means allowing the "dominating"</div> <div style=3D"font-family:arial,helvetica,sans-serif">.rcs marker to be a f= ile, similar to .git. If it is a file then it is</div> <div style=3D"font-family:arial,helvetica,sans-serif">a "file system a= gnostic" symbolic link to an out of tree .rcs</div> <div style=3D"font-family:arial,helvetica,sans-serif">directory. The = contents of this file is</div> <div style=3D"font-family:arial,helvetica,sans-serif"><br> </div> <div style=3D"font-family:arial,helvetica,sans-serif"> rcsdir:= <path></div> </div> <div><br> </div> <div class=3D"x_gmail_default" style=3D"font-family:arial,helvetica,sans-se= rif"><br> </div> <div class=3D"x_gmail_default" style=3D"font-family:arial,helvetica,sans-se= rif">Does this seem too crazy? Any implementation suggestions?</div> <div class=3D"x_gmail_default" style=3D"font-family:arial,helvetica,sans-se= rif">Where is the relevant search logic implemented in the rcs</div> <div class=3D"x_gmail_default" style=3D"font-family:arial,helvetica,sans-se= rif">source?</div> <div class=3D"x_gmail_default" style=3D"font-family:arial,helvetica,sans-se= rif"><br> </div> <div class=3D"x_gmail_default" style=3D"font-family:arial,helvetica,sans-se= rif">/john</div> <div class=3D"x_gmail_default" style=3D"font-family:arial,helvetica,sans-se= rif"><br> </div> </div> </div> </body> </html> --_000_AM6PR0302MB31898553DCED782B5E2E0D86E6889AM6PR0302MB3189_--