4 ms·

> Many GNU, Linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to Windows. However, those projects are

by gkya 11y ago

> Many GNU, Linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to Windows. However, those projects are either old, abandoned, hosted on CVS, written in platform-specific C, etc. I have seen such a paragraph in another projects README, IIRC a Go rewrite of standard utilities. I do not understand why a project would be obsolete because it's on CVS or is old. CVS is simpler than Git, albeit less capable. I, for one prefer it over Git for this reason, and others may do so too. Why would the end user care? And why would we care about the age of a programme if it works? Now, that said, the authors need not justify anything, they are free to do whatever they want, and I guess it's fun to code this stuff. I tried this just to play with Golang when it was 1.1. And lastly, that Makefile is really a bunch of shell scripts, and some common environment variables. There is no real dependency tracking in it, and it is easier to maintain a bunch of shell scripts than a seriously ugly and complex Makefile like this. N.b. that when I say dependency tracking I mean dependencies among input and output files of processing commands, not tasks. I guess Cargo would know how to do that, and how to not build if the build artefact is already there. It's a useless use of make. And that makefile is very GNU-specific, not complying with a project whose purpose is to be cross-platform. Also, I guess, tho I'm really unfamiliar with Rust and Cargo, if that makefile was removed, maybe on Windows they'd be able to drop development dependencies on Cygwin or Msys.

micampe 11y ago
I could see preferring svn to git because of the simpler model, but cvs? No thanks, a vcs without atomic commits is not much better than snapshot archives, maybe worse actually.
- maaku 11y ago
  Sometimes snapshot archives is exactly what's needed.
- gkya 11y ago
  For my use case, it's way more preferrable: a) SVN seems daunting and complex, tho I didn't ever dive into it. CVS is so simple and easy, a half-arsed programmer like me can actually understand it. Things like git and mercurial are way more complex. b) RCS is real handy for single files, e.g. a free-standing text file or shell script. But when the thing grows up, it is very easy to integrate the fileset into a CVS repo preserving it's history: move the ,v files to $CVSROOT/$MODULE/. c) The repository model of CVS is as transparent as it gets. d) The keywords like $Id$ are really useful. e.g. I keep my system configuration in "~/Checkouts/system-config", and I have a script that cp's the files to appropriate locations using a map file. When I'm not sure if the active config is not up to date, I can verify very easily. And I can be sure that dirty files won't be active as long as I don't expressly copy them. I know that SVN has this too, but I find CVS easier to use in general. I guess for fast paced, very active development, yes CVS is sub-par, but for personal stuff, or for something that is patched say at most two-three times a month, it's O.K. It boils down to personal preference.
  - jfoutz 11y ago
    there are two things that are nice about svn if you use it just like cvs. 1, atomic commits. I edit ten files, that's one checkin, rather than the per file checkins of cvs. On a low volume project, not a big advantage. if you've ever conflicted on a bigger project with cvs, it can be kind of a pain to resolve. seeing the whole commit of the other guy is helpful. If you don't run into this more than, say, monthly, it's not worth it. 2. offline diffs. svn has a whole copy of the repo, so you can compare history even if the central repo is down, or you're working from the beach. This one is pretty nice regardless. svn is a pretty nice upgrade, if you're working with a distributed team.
    - gkya 11y ago
      All appreciated, but nowadays my biggest repo is my emacs config, some tens of thousand SLOCs, about 2000-2500 of which I authored (I commit packages I use too, no elpa). And my repositories are local, i.e. they are in /var/cvsrepos. Other than that, I admit that SVN is indeed superior. I believe that one should use the best tool for the case, not the overall best tool in every case. That said, I'll give a look at SVN. I can consider switch when I have the time if it is easy to import from RCS, because I do use it a lot here and there, mostly for plain text documents. I do not like maintaining unrelated things in a single repository.
      - jfoutz 11y ago
        If it's just you, everything is local, it's probably not worth the overhead. Sounds like you have a good, efficient setup. If you're learning for the sake of learning, i'd dig into git. i'm getting better, but some cases still frighten me.
        gkya 11y ago
        > If you're learning for the sake of learning, i'd dig into git. Well, nearly everything moved to git. I've used it for a while, mostly commit/pull/clone. I actually moved to CVS from git :) It's a bit like perl, git, you either need to be an expert at it, or else you can get going, but at the end you create a mess. > [...] it's probably not worth the overhead. Sounds like you have a good, efficient setup. Mostly, yes, but mostly because I don't really need that much more than recording my history, and occasionally looking at what I did in the past and more rarely working on short-lived branches. But there are a couple tools that if I ever code them up, I will make opensource. Tho if I ever do, and they take on, I'll use a 'just send a patch on the mailing list' approach. I believe it's easier to deal with. No flamewars on VCSes :)
3JPLW 11y ago
Agreed; I'd go even farther to say that old is a feature. Now, as a side effect of its age, it may not conform to modern-day best practices and styles… which might make it harder to fix newly discovered bugs or add new features. Heck, the increased difficulty in creating feature bloat could even be considered a feature in and of itself, too!
dankohn1 11y ago
The issue is not whether projects are old, it's whether they're well-maintained. Please see the Core Infrastructure Initiative's Best Practices Badge project for one attempt at measuring the "health" of an open source project. https://github.com/linuxfoundation/cii-best-practices-badge#core-infrastructure-initiative-best-practices-badge https://github.com/linuxfoundation/cii-best-practices-badge#...
geofft 11y ago
Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product. (Incidentally, while I think that part of the reason why Git is this way is due to design differences from CVS, this isn't essential to it being true. Git is also better than Monotone or Fossil or Bazaar, despite being much closer in design, because it has network effects that those other systems don't.)
- gkya 11y ago
  > Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product. It is very easy to contribute if you know git. But you can mess it up if you don't know. I made a two-line bugfix patch to flycheck, and heck, I was nearly pasting the patch into a comment in issues because I didn't know anything about how to make a pull request on github and how to commit so that the puller would be happy. I didn't want to do sth. embarassing and spent two hours reading and reading how to submit my patch properly. And the whole fix was made and tested in about two minutes. If only I was able to submit a dumb patch, I wouldn't have to care if they used git, cvs, or tarballs and quilt.
  - geofft 11y ago
    I can't speak for other projects, but for anything I maintain on GitHub, "Hi, I don't know how to use git, but here's a patch file" is a perfectly acceptable bug report! I'm not claiming that git makes it 100% easy, just that it makes it more easy. That said, GitHub does let you use a web-based editor to create a git branch behind the scenes and open a pull request, with no VCS client required at all. So that's a point in GitHub's favor. (Again, it's not inherent to git, and a hypothetical CVSHub could do that, but GitHub exists.)
  - Sir_Cmpwn 11y ago
    I think it's easily fair to say that git is by far the superior option to CVS, and preferring CVS over git is objectively incorrect. I think that you would be wise to invest the time in learning how to use git correctly.
heavenlyhash 11y ago
Open source is useless if the majority of people in the open community -- for whatever reason -- can't build it. If a person can't build the thing, they effectively have no power to contribute to changing it. If they have no power to contribute to changing it, it's... spiritually, missing the most essential parts of open source. This is the fundamental issue driving comments like the quote above. You can tell me that not having a dependency management system, not having a sane version control system, using "some" C compiler (sans a matrix of tests specifying a range of expected good compilers), arbitrarily fine-grained platform specificness meaning an average OSS contributor can never reasonably test their changes against all targets..... all of these things can be "worked around". But at some point, the litany of issues -- some of which take a new contributor dozens of hours to work around -- becomes a simply overwhelming barrier to contribution. It's time to admit that a foundation of workarounds in FOSS development processes at the very core of our systems is a problem. Re-writing it in language $x may not be the solution, but it's certainly understandable that there's a widespread desire for simply getting better toolchains underneath our most basic essential systems.
- gkya 11y ago
  This project does not really improve upon the situation, as it uses what it is to replace for building, and a very complex Makefile where there's no need for one. I've said nothing about dependency management as in fetching code that the project depends on. I'm talking about compilation dependencies, i.e. file a.o depends on a.c, a.h, b.c and b.h. Make is for this: a.o: a.c a.h b.c b.h cc -o ${.TARGET} ${.ALLSRC} But nowhere in the projects Makefile the rules are in this fashion. They are like shell aliases. What I wanted to say is that the Makefile could be replaced with a bunch of shell scripts that would be easier to use and maintain. For the rest, it seems that we mostly agree, tho I do not think that CVS is not sane, it's perfectly usable.
  - mzs 11y ago
    On line 4 ifneq appears which is a GNU make feature. .ALLSRC is a BSD feature. It's a fine GNU makefile. Also you should look at Cargo.toml to see better what is going on.

by gkya 11y ago

micampe 11y ago

I could see preferring svn to git because of the simpler model, but cvs? No thanks, a vcs without atomic commits is not much better than snapshot archives, maybe worse actually.

maaku 11y ago
Sometimes snapshot archives is exactly what's needed.
gkya 11y ago
For my use case, it's way more preferrable: a) SVN seems daunting and complex, tho I didn't ever dive into it. CVS is so simple and easy, a half-arsed programmer like me can actually understand it. Things like git and mercurial are way more complex. b) RCS is real handy for single files, e.g. a free-standing text file or shell script. But when the thing grows up, it is very easy to integrate the fileset into a CVS repo preserving it's history: move the ,v files to $CVSROOT/$MODULE/. c) The repository model of CVS is as transparent as it gets. d) The keywords like $Id$ are really useful. e.g. I keep my system configuration in "~/Checkouts/system-config", and I have a script that cp's the files to appropriate locations using a map file. When I'm not sure if the active config is not up to date, I can verify very easily. And I can be sure that dirty files won't be active as long as I don't expressly copy them. I know that SVN has this too, but I find CVS easier to use in general. I guess for fast paced, very active development, yes CVS is sub-par, but for personal stuff, or for something that is patched say at most two-three times a month, it's O.K. It boils down to personal preference.
- jfoutz 11y ago
  there are two things that are nice about svn if you use it just like cvs. 1, atomic commits. I edit ten files, that's one checkin, rather than the per file checkins of cvs. On a low volume project, not a big advantage. if you've ever conflicted on a bigger project with cvs, it can be kind of a pain to resolve. seeing the whole commit of the other guy is helpful. If you don't run into this more than, say, monthly, it's not worth it. 2. offline diffs. svn has a whole copy of the repo, so you can compare history even if the central repo is down, or you're working from the beach. This one is pretty nice regardless. svn is a pretty nice upgrade, if you're working with a distributed team.
  - gkya 11y ago
    All appreciated, but nowadays my biggest repo is my emacs config, some tens of thousand SLOCs, about 2000-2500 of which I authored (I commit packages I use too, no elpa). And my repositories are local, i.e. they are in /var/cvsrepos. Other than that, I admit that SVN is indeed superior. I believe that one should use the best tool for the case, not the overall best tool in every case. That said, I'll give a look at SVN. I can consider switch when I have the time if it is easy to import from RCS, because I do use it a lot here and there, mostly for plain text documents. I do not like maintaining unrelated things in a single repository.
    - jfoutz 11y ago
      If it's just you, everything is local, it's probably not worth the overhead. Sounds like you have a good, efficient setup. If you're learning for the sake of learning, i'd dig into git. i'm getting better, but some cases still frighten me.
      - gkya 11y ago
        > If you're learning for the sake of learning, i'd dig into git. Well, nearly everything moved to git. I've used it for a while, mostly commit/pull/clone. I actually moved to CVS from git :) It's a bit like perl, git, you either need to be an expert at it, or else you can get going, but at the end you create a mess. > [...] it's probably not worth the overhead. Sounds like you have a good, efficient setup. Mostly, yes, but mostly because I don't really need that much more than recording my history, and occasionally looking at what I did in the past and more rarely working on short-lived branches. But there are a couple tools that if I ever code them up, I will make opensource. Tho if I ever do, and they take on, I'll use a 'just send a patch on the mailing list' approach. I believe it's easier to deal with. No flamewars on VCSes :)

3JPLW 11y ago

Agreed; I'd go even farther to say that old is a feature. Now, as a side effect of its age, it may not conform to modern-day best practices and styles… which might make it harder to fix newly discovered bugs or add new features. Heck, the increased difficulty in creating feature bloat could even be considered a feature in and of itself, too!

dankohn1 11y ago

The issue is not whether projects are old, it's whether they're well-maintained. Please see the Core Infrastructure Initiative's Best Practices Badge project for one attempt at measuring the "health" of an open source project. https://github.com/linuxfoundation/cii-best-practices-badge#core-infrastructure-initiative-best-practices-badge https://github.com/linuxfoundation/cii-best-practices-badge#...

geofft 11y ago

Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product. (Incidentally, while I think that part of the reason why Git is this way is due to design differences from CVS, this isn't essential to it being true. Git is also better than Monotone or Fossil or Bazaar, despite being much closer in design, because it has network effects that those other systems don't.)

gkya 11y ago
> Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product. It is very easy to contribute if you know git. But you can mess it up if you don't know. I made a two-line bugfix patch to flycheck, and heck, I was nearly pasting the patch into a comment in issues because I didn't know anything about how to make a pull request on github and how to commit so that the puller would be happy. I didn't want to do sth. embarassing and spent two hours reading and reading how to submit my patch properly. And the whole fix was made and tested in about two minutes. If only I was able to submit a dumb patch, I wouldn't have to care if they used git, cvs, or tarballs and quilt.
- geofft 11y ago
  I can't speak for other projects, but for anything I maintain on GitHub, "Hi, I don't know how to use git, but here's a patch file" is a perfectly acceptable bug report! I'm not claiming that git makes it 100% easy, just that it makes it more easy. That said, GitHub does let you use a web-based editor to create a git branch behind the scenes and open a pull request, with no VCS client required at all. So that's a point in GitHub's favor. (Again, it's not inherent to git, and a hypothetical CVSHub could do that, but GitHub exists.)
- Sir_Cmpwn 11y ago
  I think it's easily fair to say that git is by far the superior option to CVS, and preferring CVS over git is objectively incorrect. I think that you would be wise to invest the time in learning how to use git correctly.

heavenlyhash 11y ago

Open source is useless if the majority of people in the open community -- for whatever reason -- can't build it. If a person can't build the thing, they effectively have no power to contribute to changing it. If they have no power to contribute to changing it, it's... spiritually, missing the most essential parts of open source. This is the fundamental issue driving comments like the quote above. You can tell me that not having a dependency management system, not having a sane version control system, using "some" C compiler (sans a matrix of tests specifying a range of expected good compilers), arbitrarily fine-grained platform specificness meaning an average OSS contributor can never reasonably test their changes against all targets..... all of these things can be "worked around". But at some point, the litany of issues -- some of which take a new contributor dozens of hours to work around -- becomes a simply overwhelming barrier to contribution. It's time to admit that a foundation of workarounds in FOSS development processes at the very core of our systems is a problem. Re-writing it in language $x may not be the solution, but it's certainly understandable that there's a widespread desire for simply getting better toolchains underneath our most basic essential systems.

gkya 11y ago
This project does not really improve upon the situation, as it uses what it is to replace for building, and a very complex Makefile where there's no need for one. I've said nothing about dependency management as in fetching code that the project depends on. I'm talking about compilation dependencies, i.e. file a.o depends on a.c, a.h, b.c and b.h. Make is for this: a.o: a.c a.h b.c b.h cc -o ${.TARGET} ${.ALLSRC} But nowhere in the projects Makefile the rules are in this fashion. They are like shell aliases. What I wanted to say is that the Makefile could be replaced with a bunch of shell scripts that would be easier to use and maintain. For the rest, it seems that we mostly agree, tho I do not think that CVS is not sane, it's perfectly usable.
- mzs 11y ago
  On line 4 ifneq appears which is a GNU make feature. .ALLSRC is a BSD feature. It's a fine GNU makefile. Also you should look at Cargo.toml to see better what is going on.