Re: [Lynx-dev] A VCS for lynx
On Sat, Feb 18, 2023 at 04:07:02PM +0100, Axel Beckert wrote: > Hi Thomas, > > On Fri, Feb 17, 2023 at 04:22:02PM -0500, Thomas Dickey wrote: > > On Fri, Feb 17, 2023 at 04:56:48PM +0100, Axel Beckert wrote: > > > On Fri, Feb 17, 2023 at 02:38:24PM +, Tom Schwindl wrote: > > > > I wonder if there is interest in a VCS for doing development work. > > > > > > AFAIK Lynx is actually developed using a VCS, namely CVS. > > > > actually RCS > > Thanks for the correction! > > I actually had forgotten that CVS is based on top of RCS and that > these tags are coming from the RCS part of CVS. > > > offhand, the only program that I work on that was in CVS was xterm > > > > https://invisible-island.net/xterm/xterm.html#related-sources > > Might be the reason why I had CVS in mind for your projects, too. But > more likely is that I never worked with pure RCS, just with CVS. > > > but that stopped in 2006. > > I see. > > > https://invisible-island.net/lynx/lynx-develop.html#patches > > Never heard of PRCS before though. I had only heard about it because Klaus Weide decided to use it (starting in March 1997). https://prcs.sourceforge.net/ PRCS, the Project Revision Control System, is the front end to a set of tools that (like CVS) provide a way to deal with sets of files and directories as an entity, preserving coherent versions of the entire set. PRCS was designed primarily by Paul N. Hilfinger, with input and modifications by Luigi Semenzato and Joshua MacDonald. PRCS is written and maintained by Joshua MacDonald. Its purpose is similar to that of SCCS, RCS, and CVS, but (according to its authors, at least), it is much simpler than any of those systems. This page is where information on the latest developments in PRCS can be found. The current release of PRCS is 1.3.1. Version 1.0 was released on September 3, 1996. Though the page says the most recent release was in 2004, the related NEWS file is dated October 2001. https://link.springer.com/chapter/10.1007/BFb0053876 PRCS is an attempt to provide a version-control system for collections of files with a simple operational model, a clean user interface, and high performance. PRCS is characterized by the use of project description files to input most commands, instead of a point-and-click or a line-oriented interface. It employs optimistic concurrency control and encourages operations on the entire project rather than individual files. Although its current implementation uses RCS in the back-end, the interface completely hides its presence. PRCS is free. This paper describes the advantages and disadvantages of our approach, and discusses implementation issues. Updating the project-files wasn't straightforward, but I only had to do that long ago. It was written in C++ (whose standardization in the 1990s was kind of lacking, making it not simple to continue using it). -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: [Lynx-dev] A VCS for lynx
Hi Thomas, On Fri, Feb 17, 2023 at 04:22:02PM -0500, Thomas Dickey wrote: > On Fri, Feb 17, 2023 at 04:56:48PM +0100, Axel Beckert wrote: > > On Fri, Feb 17, 2023 at 02:38:24PM +, Tom Schwindl wrote: > > > I wonder if there is interest in a VCS for doing development work. > > > > AFAIK Lynx is actually developed using a VCS, namely CVS. > > actually RCS Thanks for the correction! I actually had forgotten that CVS is based on top of RCS and that these tags are coming from the RCS part of CVS. > offhand, the only program that I work on that was in CVS was xterm > > https://invisible-island.net/xterm/xterm.html#related-sources Might be the reason why I had CVS in mind for your projects, too. But more likely is that I never worked with pure RCS, just with CVS. > but that stopped in 2006. I see. > https://invisible-island.net/lynx/lynx-develop.html#patches Never heard of PRCS before though. Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: a...@deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: a...@noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
Re: [Lynx-dev] A VCS for lynx
Hi, thanks for all the responses! I'm happy that I'm not the only one who thinks tarballs for patches are a bit cumbersome :) On Fri Feb 17, 2023 at 4:44 PM CET, Gisle Vanem wrote: > Tom Schwindl wrote: > > > PS: I couldn't find a discussion about this topic in the archives so I > > thought > > I'll start it here. If there is general consensus that tarballs are good > > enough > > and everything should stay as is, that's alright. > > Tarballs is an archaic relic from the 80-ies IMHO. > But you're aware that Lynx is already on Github? >https://github.com/ThomasDickey/lynx-snapshots.git > I wasn't aware of such a repo and if it does reflect recent changes, I'm excited to learn about it. Thanks! That makes it much easier to follow development. When someday, in the unforeseeable future, the codebase might fully migrate to a public git or CVS instance, ping me :D > But I'm not so sure of the state of it. A 'git pull' just now > gave me: >fatal: refusing to merge unrelated histories > As Thomas wrote in another mail, a fresh clone works. > -- > --gv -- Best Regards, Tom Schwindl
Re: [Lynx-dev] A VCS for lynx
Thomas Dickey wrote: > On Fri, Feb 17, 2023 at 08:08:12PM +, Thorsten Glaser wrote: > > > These are called "RCS IDs", but TTBOMK lynx is developed in PRCS. > > was - > https://invisible-island.net/lynx/lynx-develop.html#patches The referenced doc says: | the user community views each phase of Lynx's versions as stable -- referering to my comment archived at: https://lists.nongnu.org/archive/html/lynx-dev/2022-11/msg5.html || Thomas will be more modest, but basically every 'dev' release of Lynx || is rock steady and might as well be released as a simple point release. || Stability bugs are extremely rare. I'm a bit bemused to see my standalone opinion attributed to 'the user community' as a whole! There might be others here who would disagree; don't really know... In any case, this was used in reference to: | Currently (as of 2023), I am simplifying the versioning by eliminating | the PRCS-dependent dev, pre and rel tags -- which is news to me. Possibly good news, I think... The last version seen on the mailing list, and mentioned on https://lynx.invisible-island.net/current/CHANGES, is '2.9.0dev12'. Thomas, are we to expect that the next version will be '2.9.0.13' and we'll go forward from there with purely numeric versions? I didn't intend for you to lose the ability to use the numbering system to clearly delineate 'prerelease' from 'release' versions! It can be a useful project capability to have a 'current release' vs. a 'forward developmental / unstable' version. Many projects do this with more subtle indications, like odd vs. even last digits in one of the dotted values. Or high numbers like '97' in the last value, implying 'almost +1 on the next digit'. Do you intend to switch to something like that? >Bela<
Re: [Lynx-dev] A VCS for lynx
On Fri, Feb 17, 2023 at 04:56:48PM +0100, Axel Beckert wrote: > Hi, > > On Fri, Feb 17, 2023 at 02:38:24PM +, Tom Schwindl wrote: > > I wonder if there is interest in a VCS for doing development work. > > AFAIK Lynx is actually developed using a VCS, namely CVS. actually RCS offhand, the only program that I work on that was in CVS was xterm https://invisible-island.net/xterm/xterm.html#related-sources but that stopped in 2006. > A short > > % fgrep -h '$LynxId:' src/LY*.c | cut -d: -f2- | awk '{print $3}' | sort | > tail -1 > 2023/01/07 > > shows that these CVS tags are indeed uptodate. yes - see https://invisible-island.net/lynx/lynx-develop.html#patches -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: [Lynx-dev] A VCS for lynx
On Fri, Feb 17, 2023 at 04:44:05PM +0100, Gisle Vanem wrote: > Tom Schwindl wrote: > > > PS: I couldn't find a discussion about this topic in the archives so I > > thought > > I'll start it here. If there is general consensus that tarballs are good > > enough > > and everything should stay as is, that's alright. > > Tarballs is an archaic relic from the 80-ies IMHO. > But you're aware that Lynx is already on Github? > https://github.com/ThomasDickey/lynx-snapshots.git > > But I'm not so sure of the state of it. A 'git pull' just now > gave me: > fatal: refusing to merge unrelated histories sorry about that, but I rebased the histories last year to work around a problem with the initial exports. A fresh git-clone should be fine for the foreseeable future. -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: [Lynx-dev] A VCS for lynx
On Fri, Feb 17, 2023 at 08:08:12PM +, Thorsten Glaser wrote: > Axel Beckert dixit: > > >Hi, > > > >On Fri, Feb 17, 2023 at 02:38:24PM +, Tom Schwindl wrote: > > >> But if you guys prefer CVS, that'd be fine for me too, as long as it's not > >> SVN ;). > > Word! > > >> I wonder if there is interest in a VCS for doing development work. > > > >AFAIK Lynx is actually developed using a VCS, namely CVS. > > >shows that these CVS tags are indeed uptodate. > > These are called “RCS IDs”, but TTBOMK lynx is developed in PRCS. was - https://invisible-island.net/lynx/lynx-develop.html#patches PRCS and CVS use RCS-format for the archive files. fwiw, the git snapshots are generated - https://invisible-island.net/personal/git-exports.html -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: [Lynx-dev] A VCS for lynx
Axel Beckert dixit: >Hi, > >On Fri, Feb 17, 2023 at 02:38:24PM +, Tom Schwindl wrote: >> But if you guys prefer CVS, that'd be fine for me too, as long as it's not >> SVN ;). Word! >> I wonder if there is interest in a VCS for doing development work. > >AFAIK Lynx is actually developed using a VCS, namely CVS. >shows that these CVS tags are indeed uptodate. These are called “RCS IDs”, but TTBOMK lynx is developed in PRCS. bye, //mirabilos (de-facto upstream of cvs) -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you 13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺ 16:06⎜ Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty 17:14⎜ Thanks big help you are :-)mira|nwt: ty again 18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o 18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 23:03⎜«mithraic:#cvs» aaah. thanks 18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-) 18:10⎜«sumit:#cvs» mirabilos: oh ok.. thanks for that 21:57⎜ yeah, I really appreciate help 18:50⎜«grndlvl:#cvs» thankyou18:50⎜«grndlvl:#cvs» worked perfectly 20:50⎜ i see. mirabilos, thnks for your support 00:36⎜«halirutan:#cvs» ok, the obvious way:-) thx 18:44⎜«arcfide:#cvs» mirabilos, I am running OpenBSD. 18:59⎜«arcfide:#cvs» Hrm, yes, I see what you mean. 19:01⎜«arcfide:#cvs» Yeah, thanks for the help. 21:33⎜«CardinalFang:#cvs» Ugh. Okay. Sorry for the dumb question. Thank you 21:34⎜ mirabilos: whoa that's sweet 21:52⎜«garrett__:#cvs» much appreciated «garrett__:#cvs» thanks for your time 23:39⎜ this worked, thank you very much 16:26⎜ ok thx, i'll try that 20:00⎜«stableable:#cvs» Thank you.20:50⎜«s833:#cvs» mirabilos: thanks a lot.19:34⎜ Thanks for confirming :) 20:08⎜ ...works like a charm.. thanks mirabilos
Re: [Lynx-dev] A VCS for lynx
On 2023-02-17 14:38, Tom Schwindl wrote: > I wonder if there is interest in a VCS for doing development work. > It's kind of cumbersome to deal with tarballs and it gets > unclear/messy very quickly. I'd created a repo for personal use at one point. It wasn't too hard, putting all the tarball download links in a file (along with the directory-name it went into because IIRC there were one or two where the tarball name didn't match the directory inside the tarball, and the version number to act as the description for the commit-message), then doing something like $ git init lynx $ mkdir data $ head -1 urls.txt http://.../lynx-1.2.3.tgz lynx-1.2.3.tgz 1.2.3 $ while read URL DIRNAME DESC do wget "$URL" F="${URL##*/}" tar xzvf "$F" rsync -avr --delete "$DIRNAME/" data/ git add -A data/ git commit -am "$DESC" done < urls.txt I'm recreating it from memory, but the basic idea remains, downloading each tarball, unpcking it, then rsyncing it in a directory one level down from where the .git/ directory was (so the .git/ folder didn't get nuked ), adding/removing all the files from the git index, and then committing it with the intended message (in my case, I used the version-number as the commit-message). I ended up discarding the repo after I chasing down the issue that led me to do this in the first place, but hopefully that gives you some foundation to run with. -tim
Re: [Lynx-dev] A VCS for lynx
Hi, On Fri, Feb 17, 2023 at 02:38:24PM +, Tom Schwindl wrote: > I wonder if there is interest in a VCS for doing development work. AFAIK Lynx is actually developed using a VCS, namely CVS. A short % fgrep -h '$LynxId:' src/LY*.c | cut -d: -f2- | awk '{print $3}' | sort | tail -1 2023/01/07 shows that these CVS tags are indeed uptodate. Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: a...@deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: a...@noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
Re: [Lynx-dev] A VCS for lynx
Tom Schwindl wrote: PS: I couldn't find a discussion about this topic in the archives so I thought I'll start it here. If there is general consensus that tarballs are good enough and everything should stay as is, that's alright. Tarballs is an archaic relic from the 80-ies IMHO. But you're aware that Lynx is already on Github? https://github.com/ThomasDickey/lynx-snapshots.git But I'm not so sure of the state of it. A 'git pull' just now gave me: fatal: refusing to merge unrelated histories -- --gv
[Lynx-dev] A VCS for lynx
Hi all, I wonder if there is interest in a VCS for doing development work. It's kind of cumbersome to deal with tarballs and it gets unclear/messy very quickly. It's also difficult for new developers to get a foot into the door, speaking of personal experience. Additionally, I can't seem to find a single advantage of the current workflow besides keeping developers away ;) Personally, I'm a fan of git. Given that it's basically the standard everywhere, any developer can be expected to at least know the basics of it. But if you guys prefer CVS, that'd be fine for me too, as long as it's not SVN ;). PS: I couldn't find a discussion about this topic in the archives so I thought I'll start it here. If there is general consensus that tarballs are good enough and everything should stay as is, that's alright. But a note somewhere would be helpful for people new to the project. -- Best Regards, Tom Schwindl