|
CVS hosting.
Does anyone know of CVS (or other source control) hosting services? I've looked into one, but I don't like their security policies. (using plain text strings to login, etc.).
Suggestions?
christopher baus (tahoe, nv)
Monday, September 29, 2003
It seems to me that any Unix host that lets you have shell access would also let you run your own CVS server.
When accessing a CVS server on a Unix host, it's common to use SSH to protect the password.
Brad Wilson (dotnetguy.techieswithcats.com)
Monday, September 29, 2003
I don't think many hosting services allow you to start a daemon. Plus I want something that is super easy. The one I found does allow SSH access, but they also allow pserver, and webCVS directly over HTTP.
christopher baus (tahoe, nv)
Monday, September 29, 2003
CVS doesn't run as a daemon in a Unix environment.
Brad Wilson (dotnetguy.techieswithcats.com)
Monday, September 29, 2003
What if you want to access it remotely? Doesn't the server run as a daemon? I've never actually set up the server before.
christopher baus (tahoe, nv)
Monday, September 29, 2003
Why not run CVS on your own server rather than use an external host? CVS runs on Linux and NT.
Almost Anonymous
Monday, September 29, 2003
1) for ease of use (I don't have time to admin)
2) To allow developers that need to access CVS to be able to so over the public (yet encrypted) internet.
3) I don't have a permanent IP address, and really don't want to go through the hassle of setting up a DMZ at my home office.
Although this might be what I end up doing anyway...
christopher baus (tahoe, nv)
Monday, September 29, 2003
If you're running in *nix environments, consider GNU arch. It has no server requirements other than ssh ("dumb server").
Not to mention the dozen other ways it blows CVS's doors off.
Robert
Monday, September 29, 2003
How about http://sourceforge.net run by http://www.vasoftware.com ?
VA has a hosted version of SourceForge for commercial use.
Perhaps other posters have had experience using the commercial version and can comment on its effectiveness.
Ram Dass
Monday, September 29, 2003
CVS + SSH = the only daemon is SSH, which is already running.
Brad Wilson (dotnetguy.techieswithcats.com)
Monday, September 29, 2003
Brad,
THanks for the info. I might give that a try.
Christopher
christopher baus
Monday, September 29, 2003
Brad,
I'm trying your option using this quick guide...
http://www.semanticnoise.com/projects/cvs-via-ssh/
One major drawback is that you have to have a seperate unix user account for each user..... On a shared hosted box, that might be a problem.
Maybe I should suck it up and pay for SourceGear vault hosting.
christopher baus
Monday, September 29, 2003
It depends on who you pick for hosting. If you get a jailed FreeBSD account (which can be had for $15/month, and probably lower), then you get a virtual box with root access. You can make as many user accounts as you wish, and install whatever you wish (including CVS via daemon for pserver, if that's what you want).
Really, this seems like the future of shell-provided hosting. I can't imagine doing anything else.
Brad Wilson (dotnetguy.techieswithcats.com)
Monday, September 29, 2003
Or you could suck it up and learn GNU arch:
http://www.gnu.org/software/gnu-arch/
It's either now, or later...
Robert
Monday, September 29, 2003
Robert,
I looked at the arch website. The distribution looked a bit squirly.
christopher baus
Monday, September 29, 2003
If you want a free alternative to CVS, the answer is more appropriately Subversion, I think.
Brad Wilson (dotnetguy.techieswithcats.com)
Monday, September 29, 2003
"One major drawback is that you have to have a seperate unix user account for each user..... On a shared hosted box, that might be a problem."
Um. from the "Cederqvist" http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_2.html#SEC30
"The fourth line will grant access to melissa, if she supplies the correct password, but her CVS operations will actually run on the server side under the system user pubcvs. Thus, there need not be any system user named melissa, but there must be one named pubcvs. The fifth line shows that system user identities can be shared: any client who successfully authenticates as qproj will actually run as pubcvs, just as melissa does."
As usual, this might or might not be viable in your case. In case you actually decide to set up your own CVS, do yourself a favor and read the official manual http://www.cvshome.org/docs/manual/
Juha
Tuesday, September 30, 2003
"If you want a free alternative to CVS, the answer is more appropriately Subversion, I think. "
Well, I'll make an educated guess that you're making that assessment with no real experience with either system. I think the assessment is dead wrong, unless you're hell-bent on a CVS workalike. But that's like saying you're looking for a car, but it has to be just like a Pinto.
As to the distribution being a "bit squirrely" - can that be translated into English? This is one of the most meticulously designed and implemented free software projects I've ever seen.
Robert
Tuesday, September 30, 2003
Maybe the arch distro isn't a wierd as I thought. I opened it up and what I saw was a bunch of patch logs. I'm certainly not afraid of building open source products. I have to admit I am kind of a fan of the subversion architecture. I've installed a lot Open Source distributions over the last 10 years, and the two I really don't like to mess around with are sendmail and CVS.
I installed subversion last night. That wasn't much easier, but I finally got it working. I might be back to hosting myself, and backing up offsite.
To be honest, I really don't like dealing with many of the FSF projects. But I'll leave that for another day.
christopher baus (tahoe, nv)
Tuesday, September 30, 2003
"I have to admit I am kind of a fan of the subversion architecture."
I really wanted to like svn. I used it for over a year. The only rational conclusion I could draw from that experience is that svn is a slow and oft-broken CVS with multiple unstable dependencies and fatal design flaws for the long-term.
Aside from the things that could be fixed in a reasonable timeframe: horrendous performance on large trees, etc., there are more fundamental problems that will probably never get fixed.
The first and most serious problem with subversion is that it is the same old centralized "need write access to do anything" CVS storage model.
If you don't grok the benefits of decentralization that's ok. Because on top of that is the fact that nobody understands how merging is _supposed_ to work in svn, much less understands how it _does_ work.
Even "square 0" cases like merging back and forth between branches? Oh, well that's "post 1.0". Not to mention that 1.0 is 4+ years in the making so far.
In fact, you'll find a lot of the things that svn was supposed to fix about CVS are "post 1.0".
Contrast all this with GNU arch:
* everything that needed to be fixed about CVS (renaming files, cheap tagging, repeated merging, etc.)
* fully decentralized, "dumb server" storage model
* strong support for branching and merging, with specialized operators for common use-cases
* no special servers for hosting networked archives
* no unstable moving-target dependencies
* multiple transports: http, sftp, ftp, and others.
'Nuff said.
Robert
Tuesday, September 30, 2003
I got the impression that was arch was trying to be a bitkeeper rip off, which only started because the bitkeeper CEO wanted to make some money, and offering his software for free (as in beer) to the community wasn't good enough for Stallman. Linus I feel is much more pragmatic than Stallman.
Not that cloning software it is bad, but honestly Stallman's politics annoy me. But that is a personal gripe, and nothing to do with the technology at all.
Subversion seems to have some steam behind it.. Remember the earilier versions of linux didn't support loadable modules, and a lot people thought it was doomed to be a toy. I am not taking anything away from arch, but the web site doesn't do a very good job of selling it IMHO.
My head hurts from thinking about what I thought seemed like an easy problem. I want to write software, not install SCM programs.
christopher baus (tahoe, nv)
Tuesday, September 30, 2003
"I got the impression that was arch was trying to be a bitkeeper rip off, etc."
Not in the least, really. arch does pull the best ideas from a lot of different places, but it really bears little resemblance to BitKeeper in the end.
And Stallman had nothing to do with it until very recently when it was made a "GNU" project post-facto.
As for your head hurting about source control impeding your work. Yeah, I know - which is why I recommend making a good decision now so you don't have to go through this again later.
Good luck with whatever you choose.
Robert
Tuesday, September 30, 2003
I'm not really groking the whole distributed model. How does one pull the latest source. It goes out the each person's work station? I'm not sure I like that.
christopher baus (tahoe, nv)
Tuesday, September 30, 2003
Rather than try to explain how distributed versioning works, I'll give an example:
Say you want to fork project "Xyzzy" to work on a few features. In the centralized (CVS/SVN) model, you'd have to get write permission to the server, and branch the project there. You can't commit changes unless you have a live internet connection to that server.
If you can't get write access for some reason, you create your own CVS/SVN repository. But then, every time the main project updates, you have to manually diff the mainline, and apply patches to your version. If the mainline accepts some of your patches (but doesn't grant you write access), you'll have to manually applu the patches, and it is going to be hard work (I'm not aware of a good diif/patch tool that will help you do that. Anyone?)
Now, if you had distributed version control, you'd set up your own repository, and branch from the mainline repository. All changes / authorization are under your control, and you do not need a permission from the mainline project (all you need is read access). You work on your own repository, which does not need a live connection to the mainline repository. You can pull updates from the mainline, and you can push updates to the mainline; If they accept them, they note you as the source, so that your repository (and other that have pulled directly from you, rather than the mainline) can use that info to resolve merge conflicts.
This model is supported, AFAIK, by BitKeeper, GNU arch, Monotone and darcs. BitKeeper is probably the most complete (and surely the most expensive - I heard that it runs in K$s per seat). GNU arch is the probably the most feature complete free distributed version control.
My favourite, though, is Monotone; I think it has a better foundation than Arch does, although it is still in its infancy and lacking many features.
Don't know about BitKeeper, but arch, monotone and darcs are transport agnostic - they can use files, email, newsgroups, http servers, ftp servers, etc. A "native" server can probably improve performance for each of these, but a dumb ftp/nntp server works well. This is not inherent to the distributed model, but is apparently required to make it usable in practice.
And regarding Stallman's politics, which you may or may not like: Stallman's objection to BitKeeper was that the license might be stopping people from working on other projects. And guess what? A few months after Linus started working with BitKeeper, the terms were changed:
If you use BitKeeper, you can't work on a version control project. BitMover (BitKeeper company) made exceptions for a kernel hacker who was working on Subversion. Possibly, because Subversion does not threaten bitkeeper. But I think they'll be a bit more reluctant to make an exception for arch or monotone, which could threaten bitkeeper.
This is what stallman was afraid of, and he was right in his fear. Tomorrow, BitKeeper might start writing compilers, and then they might disallow using BitKeeper for developing compilers. Or Microsoft could buy them, and disallow using BitKeeper for operating systems.
You may disagree with Stallman, but he is right, more often than not, in his predictions. He is an idealist who doesn't like to compromise. If he weren't, GNU would probably not have happened.
Ori Berger
Tuesday, September 30, 2003
"I'm not really groking the whole distributed model. How does one pull the latest source. It goes out the each person's work station? I'm not sure I like that. "
The best way to think about it is that your archives (repositories) can span multiple computers. This is an advantage in many ways. Here's a few of the most practical:
* snappy local disk performance for day-to-day work, no matter on what computer you are using at the time.
* full-featured source control on a laptop disconnected from the network, with seamless synchronization when you hook back up
* hands-off distribution to 3rd parties without giving them write access to anything. If they can see a web page (for example) of yours, they can update at will from your archive (which you will "publish" only as you see fit, of course)
* collaborative development with off-site developers (check the price tag on ClearCase Multisite!)
And that's just the business end of things. For "open source" development, a prior post hit the high points.
Robert
Tuesday, September 30, 2003
This sounds like the gnutella equivalent to source control. I'm not sure I really like it.
What if I have a release to get out, and someone has changes that I want in release in their private repository? Now what if their repository blows up? In the gnutella world that is fine since it really isn't vital to my business if I can't download some MP3s or porn. But with that repository off line, my entire project is in flux. How is this a good thing?
christopher baus
Wednesday, October 1, 2003
I never really had a problem with Stallman before he started preaching that Linux should be called GNU/Linux. Certainly GNU has provided a lot of tools that make up a distro, but so has apache, XFree86, etc. Tar and ls don't constitute an operating system.
I think Stallman has a lot of resentment toward Linus, since the FSF was unable to produce the one piece that makes an OS an OS -- the kernel.
The FSF has really provided a working model for the free software world. That's fine. Stallman should be proud of that. Instead I believe he sees failure in the FSF for not being able to produce and entire OS, and tries to claim credit for other people's work.
christopher baus
Wednesday, October 1, 2003
Stallman should be proud of that. Instead I believe he sees failure in the FSF for not being able to produce and entire OS, and tries to claim credit for other people's work.
Christopher, it could have been worse (much worse) -
Stallman originally wanted people to use LiGnux. He only switched to GNU/Linux because some many people pointed out how bad LiGnux was.
If you do a google search on LiGnux, you'll see that some people actually used that name in the late 90's.
The LKML had an interesting message about the origin of GNU/Linux back last August. The 'Kernel Traffic' digest reprinted the message:
http://www.kerneltraffic.org/kernel-traffic/kt20020805_178.html
RocketJeff
Wednesday, October 1, 2003
> Instead I believe he sees failure in the FSF for not being able to produce and entire OS, and tries to claim credit for other people's work
I think the true story is that Stallman wishes to use the software to promote his own ideology, and he can't do that when Linus controls the kernel, and companies like Red Hat SuSE and Mandrake control the distros.
Back to version control:
I agree that Subversion looks quite complicated. I'm going to give arch a serious look as a CVS replacement.
And side note: if I remember correctly, arch was actually developed by a Joel-on-Software-stereotype starving hacker, who was literally accepting donations to pay his rent. Some on this board will see that as foolishness, but I applaud his dedication and courage.
Portabella
Wednesday, October 1, 2003
You know, I've looked at arch a couple of times.
And I just... don't... get it.
The background pages are filled with fluffy "It's the best thing since sliced bread" stuff.
Add to that the fact that it's yet another "gotta have all the unix shell crap" hackfest, and I don't get the point.
Subversion at least has a well defined architecture with portable layers that can (in theory) be implementented by anyone on anything.
Somebody tell me how arch makes my life better on my Windows box without forcing me to install cygwin?
Chris Tavares
Wednesday, October 1, 2003
"Add to that the fact that it's yet another "gotta have all the unix shell crap" hackfest, and I don't get the point."
You're right, you don't. You may be talking about the old implementation in sh. That's been replaced by a C implementation which is much better performance-wise.
My recommendation: just use it for awhile. Start using it as a "better CVS", and take advantages of the additional features when the need arises.
Robert
Wednesday, October 1, 2003
"What if I have a release to get out, and someone has changes that I want in release in their private repository?"
If you desire redundancy to protect against disk crashes or network interruptions, that's what mirrors are for. And that's why arch has mirroring tools.
Robert
Wednesday, October 1, 2003
"Somebody tell me how arch makes my life better on my Windows box without forcing me to install cygwin? "
Oh, Windows? pfft. arch is probably not for you. At least yet.
Robert
Wednesday, October 1, 2003
> Oh, Windows? pfft. arch is probably not for you. At least yet.
Well, I'm always on the lookout for better tools or development techniques. I just need a decent handle on the underlying philosophy behind arch. I can't find it.
P.S. My comments about the implementation were about the previous version, and the "system requirement" page that listed GNU Tar, patch, and diff as required tools. I assumed from that requirement that it was still using sh stuff.
Chris Tavares
Wednesday, October 1, 2003
So then I have mirrors all over the place? I still don't know if I like this. So release goes like this..
arch goes all over the internet getting various repositories, finds that one (say out of 50) repository is not available, then starts going to mirror repositories
Eventually all the files are found and pulled.
I'm still not sure how this is much better than having just one repository to back up. It sounds like this creates an administrative nightmare. If I was using this in production, I would insist that the admin pulled all repositories into a central mirror so they could be backed up and taken offsite once a week.
If I can't use it with windows, then well, I'm out of this discussion I guess. I don't mind a Unix server, but Windows clients are a requirement.
christopher baus (tahoe, nv)
Wednesday, October 1, 2003
"arch goes all over the internet getting various repositories, finds that one (say out of 50) repository is not available, then starts going to mirror repositories."
*rolling eyes*
No. You will have a release line from which you wil cut releases. When it come time to release, it's no different from any other RCS. You cut the release. There is no "going all over the internet."
The difference is that you _can_ have contributors who don't have write access to your development lines. You _can_ pull changes from them, and they _can_ synchronize their changes with your ongoing development. You _can_ develop on a laptop. You _can_ develop on different machines with local performance. You don't _have_ to do any of that, and you probably wouldn't, initially. But you'd be damn glad it was there when you realized you needed it.
If you want to ensure access to those remote archives, you _can_ mirror them - just as you would any kind of information you want reliable access to, there is nothing special about this case. But once you've merged a patchset, you no longer need access to it remotely. There's no "searching all over the internet" for stuff. There's simply no _requirement_ for centralization, although you certainly can choose to do everything in a centralized way if that's what you want.
Robert
Thursday, October 2, 2003
I don't know why you are rolling your eyes at someone not understanding the implications of a radically different approach to version control. When you say "cut a release," the question remains, does the system go to Bob's laptop in Des Moines or not. How does a central repository prevent you from using a disconnected laptop? I'm doing it right now. I don't think it does.
christopher baus
Friday, October 3, 2003
There's a company called tektonic that offers virtual unix kernels starting at $15 a pop. I found them when I was looking for a virtual host to put my own CVS repository.
Their product is different than a chroot jail. You really do have your own kernel with real root access. You can install and run any software you want, and the price is good.
Here's a link to their plans:
http://www.tektonic.net/vds.php?op=plans
You could easily set up a CVS server on one of their plans.
NOTE: I'm not an owner/employee/investor of tektonic. Just a satisfied customer.
Benji Smith
Friday, October 3, 2003
The FreeBSD jail system is not the same as a "chroot jail", nor the jailshell. It is more similar to the virtual Linux system, although the implementation details are quite different. You do have root access, but you can't choose your own OS.
Searching the web for "FreeBSD jail" yields a lot of valuable information. From a service provider standpoint, a FreeBSD jail is much easier and more lightweight system to maintain, and the admin demands on the account owner are much lighter than the actual full admin needs of a virtual Linux system.
Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, October 4, 2003
""How does a central repository prevent you from using a disconnected laptop? I'm doing it right now. I don't think it does.""
Can you switch to a different branch while disconnected ?
Can you create a new branch for testing some feature while disconnected (and, of course, have it available to everyone else once you reconnect?)
Can you and another person collaborate and exchange patches and updates between one another without access to the central server? (e.g., you check out his branch, and he checks out yours, and you can both commit updates to both branches. And of course, you expect everything to be available on the central server once you reconnect...)
The various distributed version control systems allow these scanrious. The centralized systems do not.
I know GNU/arch and Monotone do, and I _think_ BitKeeper does (but I've never used it myself). I also know CVS, SourceSafe (and almost surely ClearCase) do not.
Ori Berger
Saturday, October 4, 2003
ProjectLocker ( http://www.projectlocker.com ) offers managed CVS hosting plans for $20 or less monthly. ProjectLocker manages all the configuration and administration, and might be exactly what you're looking for. ProjectLocker CVS Hosting is secured with SSH and you can use whatever client you want. You can get up and running with ProjectLocker without seeing a Unix prompt*!
Disclaimer: I work for ProjectLocker.
* - unless you use Unix on your end!
Runako Godfrey
Tuesday, January 20, 2004
SourceHosting.Net ( http://www.sourcehosting.net/ ) also provides hosted CVS repositories with the following features:
- Secure server Web-based user administration
- End-to-end SSL encryption for CVS client/server access
- Supports any CVS client, as well as folks behind restrictive firewalls or proxies
- Daily offsite backups for all repository contents
- CVSweb for browsing your repository through our secure server
- Email notifications for file commits
- Bugzilla bug database hosting in beta, available for general use in February, 2004.
- Low cost ($0 setup + $50/mo for 5 users)
If you have any questions or would like some client references about the service, please send me an email.
Best regards,
Greg Larkin
Greg Larkin
Friday, January 23, 2004
http://www.wush.net/
Private SubVersion hosting
Don Jewett
Thursday, May 20, 2004
 Recent Topics
Fog Creek Home
| 
