Comment by _pfxa | Hacker News Reader

Comment by _pfxa | Hacker News Reader

> 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.

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.

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.

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.

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#...

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.

Sometimes snapshot archives is exactly what's needed.

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.

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.

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.

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.

> 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 :)

SVN is way simpler at the interface than CVS, you should really look into it. SVN is a spiritual successor to CVS, and is trivially easy for a CVS user to pick up. We switched from CVS to SVN at work several years ago and everyone was happy with the change.

We did the same and plenty were _unhappy_. In the end git took over.

There were plenty of things I didn't like about SVN (separate folders per branch? yuk), having used CVS, and didn't find it 'trivial' to pick up.

Really, it's hard to handle branching worse than CVS does, and if SVN doesn't do a stellar job either, I don't see it as a barrier to switching.

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!

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.)

> 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.

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.)

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.

Objective truth is second to factual productivity. I did use git. It's powerful, but more than I need. CVS takes ten pages of reading to grok. And then it's out of my way. I couldn't learn git in years, and there's something new every other day, it gets in my way. And I don't have time to chase a command line on stack overflow, I need that time for what I'm actually doing.

If you want to contribute to the Linux kernel, that's how it works as well. You just mail your patch and don't need to know anything about git.

Reply on news.ycombinator.com