Slashdot Mirror

I have been using Giteye ( http://www.collab.net/giteyeap... ) to manage my git repositories, it is very powerful and full featured. I particularly like its merge tool. I don't type git commands anymore except when I am making some kind of script that needs to get stuff into or out of git. It also integrates painlessly with github and many other Issue tracking tools.

There are a few disadvantages in using it though:
1) You have to learn how to do stuff you already know how to do in the CLI (mildly annoying).
2) You need to create a free account on a service to continue using it after a month (a little annoying).
3) It is build on top of eclipse though, so it consumes a few hundred megabytes of memory (very annoying if you have an underpowered machine).

The developers at my company, who use windows laptops, keep a lot of their code in VisualSVN server and then use eitherAnkhsvn to do the checkout straight into Visual Studio, or TortoiseSVN if you want to be able to right-click in any folder and checkout to that location.

Maybe he meant AnkhSVN?

AnkhSVN is recommended if you're in a .Net environment, use a SVN server, and like to have IDE integration.

oops - typo. "Sparse checkout". You can checkout a partial directory structure, update and commit as required.

So if you have a 12Gb source tree stored in your repo, you don't need to get it all out - only the parts you want to work on. Typically you checkout the root item only, then update the required directories to fetch them into your local drive as you need them.

Which in turn has a link to the software - http://www.collab.net/products/sfee/demo/

Looks like SoftwareForge isn't FOSS, but Collabnet's TeamForge (which is fair enough, but disappointing as I wanted to run military open-source software, just to tell my boss that if its good enough for the DoD, its good enough for us!

Rewriting the same file over and over is known for being risky. The proper sequence is to create a new file, sync, rename the new file on top of the old one, optionally sync.

Except on Linux you must sync the parent directory as well. None of this behavior is usefully documented anywhere, so it's upsetting when kernel developers tell application developers they're doing it wrong.

RTFPS (Read The Fine POSIX Spec).

I've RTFPS (well, not quite - the Single Unix Specification; where do I find the Fine POSIX Spec free online?).

I am...dissatisfied with this answer because POSIX appears to provide so few guarantees that applications basically have to assume more than it promises to get anything done. The Linux documentation doesn't appear to promise anything more. For instance,

• If I create a new file and fsync it, am I guaranteed that it hit disk? (Hint: on Linux this isn't true according to the #ifdef linux block of this file. It says I must fsync the directory, and nothing in Posix even says it's possible to open() or fsync() a directory; you have to use opendir().)
• If I overwrite or append just a few bytes of an existing file and lose power before calling fdatasync(), what is guaranteed about the contents of the file? If you say "nothing", the only safe approach to updating anything is to write a complete replacement for the file, fsync() it (but pay attention to the special Linux case described above), and rename() it into place. Of course, that's a pretty significant performance hit and basically screws over any reasonable way of implementing shadow paging or write-ahead logging.

So...where is the specification that describes the filesystem's behavior in a useful way?

Disa frequently outsources it projects and this is one example of where the contractor didn't coordinate with his govt poc to obtain domain and PKI certs.

http://www.collab.net/news/press/2008/collabnet-disa.html

I work in Army IA division and this happens more often then i care to admit.

Currently, all merging must be manually tracked separately from Subversion itself.

Are you saying that the merge-tracking introduced in 1.5 doesn't work at all?

Subversion usability leaves a lot to be desired (although the book is really nice). For example, cd into a working copy that you've never seen before and try to determine its exact repository URL.

Uhh, ok.

$ cd tortoiseSVN
$ svn info
Path: .
URL: http://svn.collab.net/repos/svn/trunk
Repository Root: http://svn.collab.net/repos/svn
Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
Revision: 33826
Node Kind: directory
Schedule: normal
Last Changed Author: hwright
Last Changed Rev: 33826
Last Changed Date: 2008-10-21 15:16:27 -0500 (Tue, 21 Oct 2008)

That was tough. I think I broke a sweat.

Subversion usability leaves a lot to be desired (although the book is really nice). For example, cd into a working copy that you've never seen before and try to determine its exact repository URL.

Uhh, ok.

$ cd tortoiseSVN
$ svn info
Path: .
URL: http://svn.collab.net/repos/svn/trunk
Repository Root: http://svn.collab.net/repos/svn
Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
Revision: 33826
Node Kind: directory
Schedule: normal
Last Changed Author: hwright
Last Changed Rev: 33826
Last Changed Date: 2008-10-21 15:16:27 -0500 (Tue, 21 Oct 2008)

That was tough. I think I broke a sweat.

I am interpreting the O.P.'s information request as a request for endorsements for a product suitable for building an online community for a call center and not a request for an already active online community for a call center. I am also assuming that the call center is for an ISV. Here are a few recommendations that are my favorites.

• My favorite open source product for this sort of thing is GForge. It's got lots of call center friendly features and is also a hit with the coders.
• The full featured yet non-open source version of GForge is SFEE.
• Please don't mod me down, post nasty replies, or take away my karma points but may I feebly and humbly suggest my own product Code Roller? It's not open source yet but it is free (as in beer). Code Roller is not currently a perfect fit for call centers but has lots of great features that are conducive to managing the full life cycle for software development.

As a programmer, what pisses me off most about subversion is... well just check out their codebase and look around a bit. Yeah, it works and it does 90% of what people want it to, but the code is a giant piece of shit. That svn has been developed as a total hack job and they seemingly have spent no effort over time trying to clean it up, as a programmer, offends me. I don't know how anybody can have confidence in svn when they can't even do simple changes to it.

They've been working for years to do simple things like just updating their folder structure so it doesn't leave ".svn" folders everywhere.

Or just providing an option to not store a second copy of your 2 gig repository just so you can do restore to Head (and that's all) without asking the svn server which is probably over in the closet on the gigabit ethernet anyway. They can't do this with their current code...

it's so bad that they are trying to scrap the local store code entirely.

... and then there are the even simpler things like why tf can't I say "svn mv *.[ch] newfolder/" or any of the other commands that you have to use shell scripting to accomplish? That kind of thing should be simple.

There are a lot of these kinds of problems in svn that never gets fixed

(despite having a guy at google that is apparently paid to hack on svn)

This probably should have been in the summary -- merge tracking is being added in 1.5, so bouncing changes from one branch to another is now easy. This is a huge feature, and something as I recall Linus specifically complained about in his talk.

http://blogs.open.collab.net/svn/2007/09/what-subversion.html

BTW, they did a really nice job of mapping out the use cases and whatnot before implementing the feature. I guess source control people are natural planners.
http://subversion.tigris.org/merge-tracking/requirements.html

Anyway, I'm sure the world will continue to have need for both distributed and client/server source control systems, and Subversion is a nice example of the latter.

Quick, someone use svnsync to download the subversion history of the project!

Exactly. With a centralized version control system (PVCS, which is not coincidentially listed as the riskiest bet on the Forrester Source Code Management comparison) I've used in the past at a large company, everyone ended up making several different local copies of the code with various changes, in order to revert if necessary. I was dumbfounded - isn't that what version control is for, to keep track of changes?

FOSS is a movement not a plug in for Visual Studio. Of course as you well know you can check in code to Subversion if that what is your talking about? What would hold you back from checking in files does file exployer scare you?:) From looking at http://open-source.open.collab.net/open-source.htm l what google churned up when I searched for 'FOSS Development': I am not sure which plug in your talking about or if you understand what a IDE plug-in is. FOSS seems to not be a very major movement considering the randomness google brings up. You think the organizers of FOSS would of least made a site for it.

Maybe you could be less vague. Currently you seem not to have a point. Except throwing a random acronym at me and hoping that I'll go man he sure is smart. pfft. So yea I don't think not having a point should effect peoples use of superior product.

I was under the impression that even with FSFS you still needed to use the hotcopy.py script in order to get a guaranteed consistent backup.

> The folks at Google are smart, but they're not experts at everything.

That might be the case, but you can bet they are experts at Subversion. C'mon -- Greg Stein, Ben Collins-Sussman, Brian Fitzpatrick?! These guys helped to start the Subversion project. And as former CollabNet employees, they know a thing or two about hosted, integrated developer tools, too.

Subversion. http://subversion.tigris.org/

What you are describing is a source control system applied to documents instead of code. By design any files in the subversion repo are accessible via url. And you can restrict access using apache httpd access controls.

For example, here is a subversion repo: http://svn.collab.net/repos/svn/trunk/

notice you only needed a browser to get to it. If you use TortoiseSVN as your client, you can grab a copy using Window Explorer as a file-friendly client.

Here's a screen shot of TortoiseSVN:
http://tortoisesvn.tigris.org/

Access via apache httpd is through web DAV, so you can put it in your network share list as well.

Although trac is quite good and integrates well with SubVersion, it has a few disadvantages, the main one being no support for multiple projects.

Scarab, the open-source bug tracking tool that CollabNet's commercial offering uses and GForge, although cumbersome to setup are IMHO better alternatives if you're looking for bug-tracking tools to use along with SubVersion

--
Ravi

svnadmin create --fs-type fsfs

If you are using a version earlier than 1.0.8, you should certainly upgrade. You should be keeping track of securify fixes for any product you use on a regular basis, of course.

So, yes, if you are using a older version (less than 1.0.6), Subversion does have those particular security flaws. But the current version (1.1.1) certainly doesn't. And you should be keeping track of security fixes no matter what product you are using.

Subversion itself has been self-hosting with Subversion since 2001. Subversion 1.0 source is currently hosted on Subversion 0.37.

As I type this, version 1.0 of subversion has not been tagged yet

Now its there, but note that binary packages won't be available for a week or so.

I think slashdot may have jumped the gun here, and I hope that the slashdotting of their web server is not going to cause them problems with actually getting 1.0 out the door, which is supposed to happen sometime Monday (timezone unknown).

There seems to be another similar service up and running now however.

This is what I thought collab.net was created for, but that seems to have died. This idea is also represented, in a representative form, in Transgaming's voting system. It is a fantastic idea, as you have presented it, and I hope it comes to fruition.

I'd suggest discussing this on a non-OSDN sponsored forum. Whilst I trust editorial integrity here, any positive appraisal of Sourceforge will (quite rightly) come under suspicion, with this being the major money-maker for those bank-rolling this site.

But sourceforge isn't a VSS competitor - it's a whole-process management system. Its competitors are Clearcase, Sourcecast or the free system aegis. Clearcase has its own source control system but the others are built (AFAIK) on top of CVS - *that's* the VSS competitor here.

Subversion does look somewhat better and cleaner than CVS. But there are lots of add-on tools for CVS that will need to get ported (GUIs, servers, web interfaces, IDE integration, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--CVS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.

Good point, but this is also a big concern of the Subversion folks. This is why subversion looks so much like CVS. The commands and aliases are almost all the same, and a great part of the comportment the users see also is.

The ViewCVS scripts has already been ported to SVN, though it's not perfect yet, it does work. The GUI is pretty much in development indeed : RapidSVN is a working one, yet not complete either. An Emacs mode, similar to the CVS mode, shouldn't bee too hard to code I suppose, this is just a matter of time, will, and knowledge of elisp :)

There was talkings about using SVN as a backend for a wiki too, this could be fun and really nice. A first draft had been coded by Greg Stein (if I'm not mistaken), but it was mostly test stuff.

Subversion still needs help and contributors. People keep whining about CVS not handling file renaming etc, and they also keep using complicated tricks to avoid those flaws. I know, I've done it too. The very same people look at subversion and say "mh, nice, but not mature yet, let's wait it grows up a little". I doubt it'll grow quickly on its own, it just needs some help from all these coders who *will* use it in a few months/years !

Believe me, once you've switched to svn, it just looks life is *so* easier. Try it, it won't bite, and you'll most likely love it !

Yes, try reading the FAQ.

http://subversion.tigris.org/project_faq.html#cv s2 svn.

So far, its "only" a Python script. Very much in beta, the usual warnings apply, but they claim it's working ok.

As an example, the whole first
year of Subversion's own history was converted from CVS into a
3000+ revision svn repository. It took about 30 minutes.

http://svn.collab.net/repos/svn/trunk/tools/cvs2 sv n/README

Please check out hot-backup.py. It doesn't do much more than cp, but it doesn't just do cp repository backupdir. It copies the logfiles last. That's important.

> Noone in their right minds uses this.

Right, no one uses its authentication for anything important. CVS doesn't have a decent protocol. For extra annoyance, they do use it for anonymous stuff, since it is not good to have a Unix account for anonymous people. So you need two different ways of accessing CVS.

> > The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access.

> It's a 'kludge' that works extremely well, and fits well into the unix philosophy.

No, it does not work well. There's not a lot of Java code available to talk ssh, for example. It's not good for cross-platform stuff.

Also, ssh handshakes are time-consuming. This is important because cvs reconnects for each operation. In contrast, HTTP has well-defined and well-known standards for keepalive and pipelining.

> > It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that.

> False. It requires that they have an account on the system, not one necessarily that allows you to execute a shell (just like SourceForge has it set up).

I'm afraid you have me at a disadvantage - I've not seen SourceForge's setup. I'm not a committer on any projects there. However, ssh requires a shell account - it might be a restricted shell of some sort, but they need a shell.

Also, the manual certainly has no better way. If you are able to do so, please patch it. I quote:

It is possible to grant read-only repository access to people using the password-authenticated server (*note Password authenticated::). (The other access methods do not have explicit support for read-only users because those methods all assume login access to the repository machine anyway, and therefore the user can do whatever local file permissions allow her to do.)

There are a lot of things not possible to do with Unix file permissions. Saying things can be added but not modified. (You can have setgid directories, but not setuid ones.) One group that can read/write, one that can read, everyone else who can do nothing. Permissions within the files (short of splitting them into more files, which makes Subversion's ACID semantics difficult) . All of these things are possible with Subversion - you just write a Perl script that inspects the transaction and allows or denies it. Please take a look at commit-access-control.pl for an example.

> True. But this has little to do with the transport protocol.

You need a smart server to accomplish this. Subversion's :ext: method of remote access (rerunning the command on the other machine through [rs]sh) doesn't qualify. Arch's modify-via-ftp doesn't either. Those can't ever do anything but the Unix file permisssion way, but with a server between it can decide what is allowed or denied.

You notably didn't quote/comment on my points about why HTTP/WebDAV/DeltaV was a good choice. They clearly needed a protocol of some sort. I think using the existing standards was a good choice. Why would something else be better? Why would you not use HTTP? You said:

> CVS uses ssh which is much more reliable and secure than yet-another-protocol-over-HTTP.

Do you have anything to back that up? How is HTTP/TLS/WebDAV/DeltaV unreliable or insecure?

If you're that dead set against that protocol, write a new one. It already has the abstraction - both ra_local and ra_dav are supported. Write a new ra_XXX if you so desire. And a new server to replace mod_dav_svn. Of course, no one will use it - the DAV stuff works well. But maybe you'd feel better.

I notice that they don't even use subversion themselves. Instead, they use a seemingly closed-source commercial product called SourceCast.

At work, we use CVS. While not everyone on the project uses it well, we end up using it effectively. We have had problems with people accidentally backing out changes because they didn't check their `cvs diff`, but other than that no other real problems.

I have not tried it myself, but I have heard very good words about subversion, a version control system which is in heavy development right now. The developers have looked at various existing version control systems, and found their pros and cons. Then they designed a sane system, something between CVS and Perforce. Then they started coding.

Subversion is not finished yet, but according to others, it is quite usable already, and the subversion developers are using it themselves.

There was an article in Linux Journal about subversion i February.

In particular, I'm curious about Asynchrony because it might be effective for a self initiated community project to acquire the use of Asynchrony's sales and marketing arms. But I find what seems to be a contradiction in their terms of service.

Here's an excerpt from Asynchrony's FAQ:

..."there is really nothing to stop someone from downloading an open-source project from somewhere else on the Internet and submitting it. However, our standards for certification will require significant work in documentation, so anyone doing this would really have to be familiar with the project. As long as we continue to distribute the product under the open-source license it is under, there is really no illegality there."

"As stated in the code rights section, we really need to own products to be able to market them effectively. If you are willing to give up ownership in return for 75-90% of the product's net revenue (as well as the resources of the Asynchrony membership to help you improve it), then we can definitely help you."

Why should a third party need to own the copyright of an open source work (GPL, BSD, etc) in order to effectively market and sell it?

Why is VP3 different with respect to patents? On2 has patents, they seem doing a good thing and try to let people use their IP. But they could be bought in a heartbeat and work that you and others put into it would be gone.

What they should do is give the patent to a conservancy, like collabnet's or the Knowledge Conservancy.

svn is the name of the command line client for Subversion. Since Subversion uses WebDAV for its network protocol, all of your head is browseble directly over the web. Try going to http://svn.collab.net/repos/svn/trunk/ to see an example of this up close.

You could hire contractors on a time contract to assist an open source project that is already going in a direction you think will be valuable to you; or you can go through the standard RFP process to contract for the development of a custom software solution, and then open source the resulting code, but even doing that isn't trivial.

There are companies like CollabNet who specialize in forming communities around software that companies want to open source. Or you can start the community yourselves, but community building is a labor of love -- it takes forever, and you have to be committed. I speak here from personal experience since we tried to form a community around a product we initially wrote internally and failed miserably in attracting a wider community of interest.

There are a few open source projects that are centered around consulting companies; Jabber is one, but there is also MySQL, Zope, and Lutris among others. If your problem fits one of their areas of expertise, then by all means send them an RFP; but you can't RFP the world. It really doesn't generate interest in people who don't already have a contracting mindset.

I'm probably out of date, but I thought that was collab.net's and SourceXchange's purpose: bring together people who want code and have money with people who can make code and want money.

I'd think that it'd be easy to make the RFP there, then send a note to the developers/project mailing list steering them towards it.

No?

--j

The above is not correct, and in fact, no one has been able to cite an example of a profitable open source software company. Cygnus was privately held and so it's hard to figure out if it was proftable or not, but it was definitely not "greatly profitable." However, it's easy to do a back-of-the-envelope calculation based on its $20M in annual revenues and 180 employees at the time of its acquisition. The cost of maintaining 180 employees in a technology company in the SF Bay Area is more than $18M annually, and there are other costs of doing business, so if the company was profitable at all, it was just squeaking through. (And $20M in annual revenues after ten years of existence is no one's idea of "greatly profitable.")

Red Hat has yet to turn a profit, though it keeps promising one real soon now.

Mandrake is losing money. According to its financial disclosure, as translated by BabelFish:

Since its creation in November 1998 the company recorded losses. The cumulated amount of the overdrawn turnover of the group accounts between September 30, 1999 and 31 March 2001 amounted to 13,7 MEuros is approximately three times the amount of the turnover over the period. In spite of a strong progression envisaged of its turnover, MANDRAKESOFT considers a benefit only at the end of the exercise closed at June 30 2003;

That is, it doesn't expect to become profitable for two years.

IBM is sinking a billion dollars into open source this year. That doesn't mean it will realize any profit from this investment. It certainly hasn't earned it back yet, and whether it ever will is purely speculative.

CollabNet is privately held, so it's hard to say how much money it's made back on that $35M investment. It's announced a few deals, but refuses to comment on their size: "It's our first true enterprise development network..." It's a significant deal for CollabNet, so much so that Mills refused to comment on the size of the contract or even whether it's the company's biggest win so far. (CollabNet is still privately held.) Mills did say that there are other deals now in the pilot stage with the potential to be as big as this one. I think it's a safe bet that the company is not yet profitable.

Many consultancy companies have done well. In fact, the consultancy companies do what can't be done in the Microsoft world - they can be profitable, equal players.

Consultancies are homesteading businesses, not software companies. As already pointed out, consultancies only scale linearly, not exponentially. In any case, they aren't doing so well either. I'm not going to mention the name of one company we're partnered with, but they make a great open source product, but they're in dire straits and they're going to have to start charging for it. I imagine there are probably a few small-business open source consultancies which are bringing in six-figure salaries for their principals, but that's not enough to sustain development efforts, and it's not enough to go public.

Tim

The above is not correct, and in fact, no one has been able to cite an example of a profitable open source software company. Cygnus was privately held and so it's hard to figure out if it was proftable or not, but it was definitely not "greatly profitable." However, it's easy to do a back-of-the-envelope calculation based on its $20M in annual revenues and 180 employees at the time of its acquisition. The cost of maintaining 180 employees in a technology company in the SF Bay Area is more than $18M annually, and there are other costs of doing business, so if the company was profitable at all, it was just squeaking through. (And $20M in annual revenues after ten years of existence is no one's idea of "greatly profitable.")

Red Hat has yet to turn a profit, though it keeps promising one real soon now.

Mandrake is losing money. According to its financial disclosure, as translated by BabelFish:

Since its creation in November 1998 the company recorded losses. The cumulated amount of the overdrawn turnover of the group accounts between September 30, 1999 and 31 March 2001 amounted to 13,7 MEuros is approximately three times the amount of the turnover over the period. In spite of a strong progression envisaged of its turnover, MANDRAKESOFT considers a benefit only at the end of the exercise closed at June 30 2003;

That is, it doesn't expect to become profitable for two years.

IBM is sinking a billion dollars into open source this year. That doesn't mean it will realize any profit from this investment. It certainly hasn't earned it back yet, and whether it ever will is purely speculative.

CollabNet is privately held, so it's hard to say how much money it's made back on that $35M investment. It's announced a few deals, but refuses to comment on their size: "It's our first true enterprise development network..." It's a significant deal for CollabNet, so much so that Mills refused to comment on the size of the contract or even whether it's the company's biggest win so far. (CollabNet is still privately held.) Mills did say that there are other deals now in the pilot stage with the potential to be as big as this one. I think it's a safe bet that the company is not yet profitable.

Many consultancy companies have done well. In fact, the consultancy companies do what can't be done in the Microsoft world - they can be profitable, equal players.

Consultancies are homesteading businesses, not software companies. As already pointed out, consultancies only scale linearly, not exponentially. In any case, they aren't doing so well either. I'm not going to mention the name of one company we're partnered with, but they make a great open source product, but they're in dire straits and they're going to have to start charging for it. I imagine there are probably a few small-business open source consultancies which are bringing in six-figure salaries for their principals, but that's not enough to sustain development efforts, and it's not enough to go public.

Tim

Captain Tacky forgot to mention that Nokia is doing this in partnership with CollabNet, a very cool company based on community development, which also used to operate sourcexchange.

Hmm, I heard that jxta was actually written by collab.net, a most interesting SF-based collaboration company.... however I can't find any corroboration for this on either site, anyone got any leads on this?

Indrema's Indrema Developer's Network already HAS something similar to SourceForge. It's called "GameXchange," and, IIRC, is being handled by CollabNet.

Collab.net, and what they are doing, has been public for a while now. See the Collab website for more info on what they do. Much different than SourceForge. In fact, from what I understand, Brian was putting this together much before SourceForge was a gleam in VA's eye.

A million dollar software project can be broken into a series of different projects, each just large enough that it can be spec'd out with a reasonable set of milestones (almost always less than 15-20). Software development schedules always change based on inherent risk, so you probably shouldn't spec out a 500 milestone project. And the Sponsor always has to be someone who can check the Developer's work - so this isn't exactly "put $15K in, get good solid code out overnight" kind of thing.

I would think that if you were the project manager for a 15 person software development project, you could probably parallelize 10-15 sub-projects in sourceXchange (or less if you have multiple developers per project), all working on different things. Of course it's not always nice and parallelizable, sometimes there's only work for a few at a time - but the beauty of this model is that you don't have to pay for 15 full time developers during those periods.

There's another thing a developer can do - be a Sponsor on a project where the person actually paying is upstream, and only knows their need, not how to define a solution. In other words, let's say you (average Slashdot reader) know of someone who has a need for some sort of development (say a Linux driver for the CCD camera in the Sony Vaio Picturebook) and is willing to pay to have it developed, yet doesn't know enough about Linux kernel internals to write a spec or approve milestones. You would do it, if fact you know how you'd do it, but you don't have nearly enough time. This model lets you be the "sponsor", acting as a subcontractor to this other someone who needs the driver written, who specifies (generally) what to build and how, and then outsources that actual development through sourceXchange, passing along the cost (plus an amount for your own time and effort) to the original customer.

There's lots of flexibility in the system.

Thanks.

Brian