Believe me, we would have loved to roll this thing out sooner. This is the first time we've tried something like this, so there was a lot to figure out and to get done. Before we knew it, it was the end of May:-(
If it works out well, and we decide to do it again, then we will be much better prepared!
It is a million dollar cash outlay. Please don't forget that we're also donating money to the organizations that are helping out with the Summer of Code. $500 per project.
If you like an organization and want to see a donation go their way, then select that org on your project proposal.
Our main idea is to help out the students, but we also recognize that the OSS organizations will be helping us out, and we want to help them in return.
We didn't make this clear enough. Those are merely ideas. Come up with anything you want and write a proposal!
Feel like adding some new, cool feature to an existing OSS project? Fine. Want to write a plugin for a project? Fine.
It is limited only by your creativity. We asked the organizations to produce some lists to spur people's imaginations. Not to limit them to just those projects!
Google supports a number of Open Source organizations. We've listed those on the code.google.com site. We hope to expand that list over time. It is a lot easier for us to support (on a continuing basis) a dozen organizations than hundreds of OSS programmers.
The Summer of Code is about getting new developers interested in Open Source development. We're willing to risk that some students might not be long-term contributors, but there will be some that do!
A phrase that I have used often: "CVS is resistant to change."
I'm not kidding. I've actually made changes to CVS before. You would not believe how impossibly difficult the thing is to change without breaking it. Change something *here* and it breaks way over *there*. It is a disaster.
Please go ahead and try to extend the add command as you describe. I doubt you would be able to do it. And if you *do* get it to work, then see whether you can get it to function with old CVSs, Eclipse, NetBeans, and CVSNT.
The CVS codebase simply could not be a starting point. Period.
The disk could die, or what is worse: drop a bit here or there. Those subtle corruptions are much worse by far. Thankfully, Subversion keeps MD5 checksums of all data in the repository. When it goes to read from the disk, it can detect the corruption and tell you that a problem exists. It can't correct it, but it won't let it silently slide by... We also use checksums over the wire (not all TCP stacks compute checksums). Checksums are also retained on the client to watch for problems there -- generating a diff against a corrupted file produces some very funky results.
Anyways... if the repository gets some bit rot, then you pull out archival backups to see when it blew up. If you're really serious, then you access every file and every revision once a week. Worst case, you'd only need to fix bit rot that occurred in the past week.
This is much nicer than RCS and CVS's silent failure. I know that BK keeps checksums on disk, but I'm not sure about some of the other contemporary systems. They all *should* if you want to consider them to be a production-strength system worthy of storing millions of lines of code for years and years.
The GPL makes no reference to how you must license patents (go read it).
The statement that you quoted is in reference to the GPL saying that if you can't meet the requirements of the GPL, then you can't redistribute. One of the requirements is ensuring that the next person has the same rights as you. Thus, if one person has patent rights, but the next doesn't, then you have a situation where people have unequal rights. Thus, you're not allowing to redistribute.
As Mr Slippery quoted, "You may not impose any further restrictions on the recipients' exercise of the rights granted herein". Note the emphasis I added.
As Joshua states, the GPL doesn't give you any patent rights, so any restrictions around patent rights do not interfere with the GPL.
and will probably move all of them over at some point.
A bit more than probably:-). For security purposes, the ASF wants to transition away from shell accounts and SSH/CVS, towards SVN. Now that SVN 1.0 is released, we're going to start asking projects to (voluntarily) move into SVN. At some point in the future (year?), it will become a mandate and we'll completely disable CVS and the shell accounts.
Sure, code from the Apache Software Foundation may be free, but that does not mean that our core purpose -- providing softwre to the public -- should be held hostage to political demonstrations and statements. We altered our web page because we care about the EU patent situation (well, anywhere really!). But to completely shut down our site would fly in the face of our entire reason for existence. The ASF is a public charity, chartered to help people. Just because we make our software available for free doesn't mean it is right for us to deny access to it whenever the whimsy strikes us.
I know the founder of the company that makes the camera. He's a college buddy of mine. I asked the same question everybody here is asking, "how do you prevent somebody from just using the camera however they want?", and he said the stuff was encrypted.
My streaming server, edna has been written in Python since day one.
Yes, Subversion is in C. Our network server is Apache. Personally, I'm quite confident in Apache's resistance to exploits. (and yah yah, adding svn to apache means adding exploits, but the point is that we're on a nice base).
1) completion of a set of features 2) completion by a specific date
In my practical experience, you can never choose both. Something will always come up such that you cannot complete the features on schedule. Or you set a date and code what you can by that date.
It is a simple fact, and a good manager will understand this and ask for one or the other. You can ask for a set of features and guess at the end date, but you cannot rely on that date.
Many people believe that software engineering "techniques" can solve the planning problem. Nope. They don't work in the real world. Most of those techniques came from the industrial era, and manufacturing processes. They simply don't apply to programming.
The issue is that programming is almost always a research endeavor. You never know exactly what is going to be coded and how they will fit together. You can plan and plan and plan, but when the bits come together... it will be different.
Keep the mantra in mind: Choose One.
(well, strictly, there are three options and you choose two; the third is size of the staff, but that is usually fixed, so the problem always comes down to choose one of two) For the original poster's problem, his manager is asking for more dev time. Will this solve the problem of getting more done? It is impossible to say. Again: you never know how long a single feature is going to take. Sure, you'll get it done a bit faster on average, but hoo... the team morale will suck.
Does that affect code quality? Absolutely. What you'll see is developers cutting corners to complete a feature by a given date. People aren't going to be working 15 hour days for the sake of it. It will always be to meet some kind of goal. And because people want lives, they'll try to meet that goal with as little impact on themselves as possible. The manager has chosen time, the developers will cut features to fit that time. In this case, it will be boundary conditions, test suites, nice UIs, logging, or what have you. Those edge bits that turn okay software into great software will be dropped on the floor.
Greg points out that branches can live under a '/branch/' root - which goes some way to addressing this if everyone's working against trunk, but if we're working on a branch as a matter of course (e.g. stabilising a release) then it doesn't really help.
You followed up to yourself noting that people can use/branches/issue-10and/branches/joebob. And that is just "one way" of doing it. Organize your branches however you'd like. You could have/branches/issues/ and/branches/personal, each with further subdirs.
Say I wanted to work on a branch subprojectA1 but track trunk changes to subprojectsA2 and 3.
No problem. Use Subversion "modules" (aka "externals"). SVN has a much more flexible system for pulling together bits than CVS's module support. For starters, we can grab stuff from multiple, disjoint repositories (entirely different servers even!). Second, they are entirely user-controlled via properties on a directory. In particular, you could set up a module for yourself. Let's say that you've created/branches/Rupw/change-A/. On that directory, you set the svn:externals property to the following two lines:
Now, when you check out change-A, you naturally get A1 as part of that check out. However, SVN also sees the property, so it goes and checks out subA2 and subA3 from the main trunk. If you do an "update", then all the right bits are pulled.
A similar situation can be used to gather together the GNU tool chain from the redhat repository. We are planning to use this same feature to pull together bits for SVN development: gather code from svn.collab.net, from the ASF, from Neon, and possibly from sleepycat. As I mentioned, multi-site gathering of bits are possible in a single svn:externals property.
Regarding the $Revision$ thing. We expand that label to the last changed rev for the file in question. Thus, the keyword might say "10" even though the current revision is 23, simply because the file wasn't changed in revs 11 through 23.
And yes: it is true that CVS-style revision numbers implicitly show you branch points. But they're on a per-file basis. In SVN, you can say at a high-level "branch FOO was created from revision 1234 of/trunk". In any case, "svn log" should show you information about the branching (it technically can, but doesn't now).
Fair enough. Note that it will be much easier to do this because of the global revision number. You can fetch the head rev num (simple and fast) and compare it against what you last built. With CVS, you'd have to crawl the entire repository looking for changes to rebuild.
To print the head rev:
$ svn stat -un . | sed -n '/^Head/s/.*: *//p'
There might be some other nifty ways. Especially if you write a script that binds to libsvn_ra. There is an RA function to query the head rev.
Subversion seems to be reinventing various Perforce features (which is the right thing to do). It has a long way to go and isn't advancing that fast. I don't expect it to blow Perforce out the water any time soon.
Our intent is to displace CVS. That's it. If we happen to displace Perforce a bit... oh well. In the long run, we will impact most SCM vendors. The Perforce guys, though, seem to have a pretty good business sense: easy to use, high volume, good value-add, and bang-for-buck. I suspect they'll deal fine with SVN encroaching. It is the bigs guys like Rational that are going to have problems justifying their price and complexity.
As far as "advancing"... well, to be honest, we pretty much finished the core of day-to-day usage last fall. Since then, we've been rounding out the feature set and stabilizing the code. People need to trust Subversion to hold their source code safe. We don't want to give them cause to question SVN, so we are giving ourselves plenty of time to get it right.
Our Alpha release is next week. Most people would call it a Beta release, but it goes back to the stability thing. For our purposes, it is alpha. Trust is hugely important.
It is related to the standard "distributed repository" system, and is a very difficult problem. It is quite easy to mess up:-) Some though has already been applied to the issue, but the simple answer is:
We are replacing CVS. Further innovation and feature enhancements will come later.
IOW, since CVS doesn't have it, then we don't need it for 1.0. Our goal is to knock CVS out of use. The hundreds of thousands of CVS users don't need that kind of offline or distributed repository support, so we should be fine for now.
In the long term future? Absolutely.
(and yes, Larry McVoy is going to say that since we didn't design distributed repositories in from the beginning that we'll never be able to do it; "ha!" I say; we'll get it done, and it will work quite well)
Euh... Subversion doesn't use FTP. Icky. You are probably think about Arch. It uses FTP, and yes: that means it will send passwords in the clear. I've got to believe they have fixed that by now, and that you can use scp or somesuch, but it is rather tiresome to see a network app built nowadays that doesn't have security integrated right in, with considerations for it up front.
It appears that any developer could modify the files on the code server and make it appear that someone ELSE made a given change.
Well, yes and no. There is no obvious way to alter the author that gets recorded with a revision at commit time. However, if you have local access to the repository, then you can use the libsvn_fs APIs to alter the svn:author property on the revision.
Personally, I just don't ever plan to give people local access to my servers. One of the huge benefits of being Apache-based is that our authentication occurs through Apache, and that it does not need system accounts (it can integrate with existing auth systems (PAM, LDAP, NTLM, etc) or use text files, databases, etc). Therefore, the only way somebody could alter the author property is if, say, I wrote a CGI script that allowed a person to go and tweak it.
So the general answer is: no, a developer is not entirely trusted, and they cannot change the recorded author on revisions.
Are you possibly thinking of Arch again? I'm not sure how it records authors, or whether other developers can tweak that information.
Slashdot Mirror
Believe me, we would have loved to roll this thing out sooner. This is the first time we've tried something like this, so there was a lot to figure out and to get done. Before we knew it, it was the end of May :-(
If it works out well, and we decide to do it again, then we will be much better prepared!
It is definitely international. You're more than welcome to submit a proposal, whether you live in the US, the UK, or the Ukraine.
It is a million dollar cash outlay. Please don't forget that we're also donating money to the organizations that are helping out with the Summer of Code. $500 per project.
If you like an organization and want to see a donation go their way, then select that org on your project proposal.
Our main idea is to help out the students, but we also recognize that the OSS organizations will be helping us out, and we want to help them in return.
No no no...
We didn't make this clear enough. Those are merely ideas. Come up with anything you want and write a proposal!
Feel like adding some new, cool feature to an existing OSS project? Fine. Want to write a plugin for a project? Fine.
It is limited only by your creativity. We asked the organizations to produce some lists to spur people's imaginations. Not to limit them to just those projects!
Google supports a number of Open Source organizations. We've listed those on the code.google.com site. We hope to expand that list over time. It is a lot easier for us to support (on a continuing basis) a dozen organizations than hundreds of OSS programmers.
The Summer of Code is about getting new developers interested in Open Source development. We're willing to risk that some students might not be long-term contributors, but there will be some that do!
Any student from any country.
:-)
(except for those countries the US State Department forbids us from working with... the "terrorist" countries)
So yeah... Canadians are welcome!
And the "v" is not capitalized:
Subversion
A phrase that I have used often: "CVS is resistant to change."
I'm not kidding. I've actually made changes to CVS before. You would not believe how impossibly difficult the thing is to change without breaking it. Change something *here* and it breaks way over *there*. It is a disaster.
Please go ahead and try to extend the add command as you describe. I doubt you would be able to do it. And if you *do* get it to work, then see whether you can get it to function with old CVSs, Eclipse, NetBeans, and CVSNT.
The CVS codebase simply could not be a starting point. Period.
The disk could die, or what is worse: drop a bit here or there. Those subtle corruptions are much worse by far. Thankfully, Subversion keeps MD5 checksums of all data in the repository. When it goes to read from the disk, it can detect the corruption and tell you that a problem exists. It can't correct it, but it won't let it silently slide by... We also use checksums over the wire (not all TCP stacks compute checksums). Checksums are also retained on the client to watch for problems there -- generating a diff against a corrupted file produces some very funky results.
Anyways... if the repository gets some bit rot, then you pull out archival backups to see when it blew up. If you're really serious, then you access every file and every revision once a week. Worst case, you'd only need to fix bit rot that occurred in the past week.
This is much nicer than RCS and CVS's silent failure. I know that BK keeps checksums on disk, but I'm not sure about some of the other contemporary systems. They all *should* if you want to consider them to be a production-strength system worthy of storing millions of lines of code for years and years.
The GPL makes no reference to how you must license patents (go read it).
The statement that you quoted is in reference to the GPL saying that if you can't meet the requirements of the GPL, then you can't redistribute. One of the requirements is ensuring that the next person has the same rights as you. Thus, if one person has patent rights, but the next doesn't, then you have a situation where people have unequal rights. Thus, you're not allowing to redistribute.
As Mr Slippery quoted, "You may not impose any further restrictions on the recipients' exercise of the rights granted herein". Note the emphasis I added.
As Joshua states, the GPL doesn't give you any patent rights, so any restrictions around patent rights do not interfere with the GPL.
and will probably move all of them over at some point.
:-). For security purposes, the ASF wants to transition away from shell accounts and SSH/CVS, towards SVN. Now that SVN 1.0 is released, we're going to start asking projects to (voluntarily) move into SVN. At some point in the future (year?), it will become a mandate and we'll completely disable CVS and the shell accounts.
A bit more than probably
Sure, code from the Apache Software Foundation may be free, but that does not mean that our core purpose -- providing softwre to the public -- should be held hostage to political demonstrations and statements. We altered our web page because we care about the EU patent situation (well, anywhere really!). But to completely shut down our site would fly in the face of our entire reason for existence. The ASF is a public charity, chartered to help people. Just because we make our software available for free doesn't mean it is right for us to deny access to it whenever the whimsy strikes us.
-- Greg Stein, ASF Chairman
I know the founder of the company that makes the camera. He's a college buddy of mine. I asked the same question everybody here is asking, "how do you prevent somebody from just using the camera however they want?", and he said the stuff was encrypted.
I'll take that bet. I know for a fact that the pictures are encrypted.
The implementation language doesn't matter. Come on people, think about what this program is intended to do:
Download files over a long period of time
Do you honestly think that if your for-loop is 10 clock cycles faster, that it will make a difference? Not a bit.
Instead, as somebody else pointed out: you want to choose the language that works best for you, and is the most maintainable [for you].
My streaming server, edna has been written in Python since day one.
Yes, Subversion is in C. Our network server is Apache. Personally, I'm quite confident in Apache's resistance to exploits. (and yah yah, adding svn to apache means adding exploits, but the point is that we're on a nice base).
Good thinking, but there is no problem.
The CVS repository on cvshome.org was updated on January 15th, well before the exploit was published.
(but wow, wouldn't that have been cool? every rushes to update their copy of CVS, and now you've got your backdoor installed everywhere? hoo ya!)
Managers get to choose one:
1) completion of a set of features
2) completion by a specific date
In my practical experience, you can never choose both. Something will always come up such that you cannot complete the features on schedule. Or you set a date and code what you can by that date.
It is a simple fact, and a good manager will understand this and ask for one or the other. You can ask for a set of features and guess at the end date, but you cannot rely on that date.
Many people believe that software engineering "techniques" can solve the planning problem. Nope. They don't work in the real world. Most of those techniques came from the industrial era, and manufacturing processes. They simply don't apply to programming.
The issue is that programming is almost always a research endeavor. You never know exactly what is going to be coded and how they will fit together. You can plan and plan and plan, but when the bits come together... it will be different.
Keep the mantra in mind: Choose One.
(well, strictly, there are three options and you choose two; the third is size of the staff, but that is usually fixed, so the problem always comes down to choose one of two)
For the original poster's problem, his manager is asking for more dev time. Will this solve the problem of getting more done? It is impossible to say. Again: you never know how long a single feature is going to take. Sure, you'll get it done a bit faster on average, but hoo... the team morale will suck.
Does that affect code quality? Absolutely. What you'll see is developers cutting corners to complete a feature by a given date. People aren't going to be working 15 hour days for the sake of it. It will always be to meet some kind of goal. And because people want lives, they'll try to meet that goal with as little impact on themselves as possible. The manager has chosen time, the developers will cut features to fit that time. In this case, it will be boundary conditions, test suites, nice UIs, logging, or what have you. Those edge bits that turn okay software into great software will be dropped on the floor.
Choose One. It'll make your life hella better.
A2 http://svn.example.com/repos/projectA/subA2
A3 http://svn.example.com/repos/projectA/subA3
The A1 subdir simply lives under change-A.
Now, when you check out change-A, you naturally get A1 as part of that check out. However, SVN also sees the property, so it goes and checks out subA2 and subA3 from the main trunk. If you do an "update", then all the right bits are pulled.
A similar situation can be used to gather together the GNU tool chain from the redhat repository. We are planning to use this same feature to pull together bits for SVN development: gather code from svn.collab.net, from the ASF, from Neon, and possibly from sleepycat. As I mentioned, multi-site gathering of bits are possible in a single svn:externals property.
Regarding the $Revision$ thing. We expand that label to the last changed rev for the file in question. Thus, the keyword might say "10" even though the current revision is 23, simply because the file wasn't changed in revs 11 through 23.
And yes: it is true that CVS-style revision numbers implicitly show you branch points. But they're on a per-file basis. In SVN, you can say at a high-level "branch FOO was created from revision 1234 of
I think that answers all your questions/concerns!
Fair enough. Note that it will be much easier to do this because of the global revision number. You can fetch the head rev num (simple and fast) and compare it against what you last built. With CVS, you'd have to crawl the entire repository looking for changes to rebuild.
:-)
To print the head rev:
$ svn stat -un . | sed -n '/^Head/s/.*: *//p'
There might be some other nifty ways. Especially if you write a script that binds to libsvn_ra. There is an RA function to query the head rev.
fun fun
As far as "advancing"... well, to be honest, we pretty much finished the core of day-to-day usage last fall. Since then, we've been rounding out the feature set and stabilizing the code. People need to trust Subversion to hold their source code safe. We don't want to give them cause to question SVN, so we are giving ourselves plenty of time to get it right.
Our Alpha release is next week. Most people would call it a Beta release, but it goes back to the stability thing. For our purposes, it is alpha. Trust is hugely important.
In the long term future? Absolutely.
(and yes, Larry McVoy is going to say that since we didn't design distributed repositories in from the beginning that we'll never be able to do it; "ha!" I say; we'll get it done, and it will work quite well)
Personally, I just don't ever plan to give people local access to my servers. One of the huge benefits of being Apache-based is that our authentication occurs through Apache, and that it does not need system accounts (it can integrate with existing auth systems (PAM, LDAP, NTLM, etc) or use text files, databases, etc). Therefore, the only way somebody could alter the author property is if, say, I wrote a CGI script that allowed a person to go and tweak it.
So the general answer is: no, a developer is not entirely trusted, and they cannot change the recorded author on revisions.
Are you possibly thinking of Arch again? I'm not sure how it records authors, or whether other developers can tweak that information.