It sounds like you're assigning meaning to the individual revision numbers on files. So you know that create_db.sql version 1.14 is special somehow and people understand these numbers mean something.
That's fine, and if it's working for you you don't need to change it, but personally I find it hard to remember that in version 1.15 I added a new table and that branched version 1.2.4.15 corresponds to the current production code.
In Subversion you'd use symbolically named tags, which are copies of directory trees, in order to remember that kind of thing. So you might have a bunch of files in your repository corresponding to your released software, in directory
/myproject/tags/release-1.0/sql/...
In your example a single revision number is useful because a change to SQL code usually involves a change to other code. For example, if you rename a column you'll need to change application code that accesses that column. If you commit all these changes in one go, logically grouping them together, it makes things a lot clearer when reviewing changes later on. Once you have changes grouped together as a unit you can move them around, apply them to other branches, or even back them out if they don't work.
Grouping changes like this together probably also implies some stuff like having database people sit with programmers and pair on their changes, but I'll avoid going off the deep-end and evangelising XP too much...;-)
The book does discuss the differences between the per-file (CVS) and repository-wide (Subversion) numbering schemes, although the conclusion is that the differences don't matter that much.
Basically if you're using version numbers on files to figure out "how much has changed recently" you should be probably looking at the log/history instead. Even if a file in CVS has only been incremented one revision point, the change could actually have altered every line in the file. The numbers don't really give you concrete information about how much "churn" is going on in the code.
I'd recommend using decent log messages and keeping commits small and specific over using revision numbers to figure out what's changed.
When I was initially getting involved with Subversion I found that most of its features reminded me a lot of Perforce. The repository-wide revision numbers, database backend, and general "feel" of Subversion is very similar to Perforce.
I think Perforce is better than Subversion if you're doing a lot of branching -- the merge point tracking that Perforce performs is really well implemented and saves you from a lot of manual tracking. Overall though if you're looking for a free alternative to Perforce I'd highly recommend Subversion
If cost isn't the issue, then what is? For MS-only shops, the issue is the MS-only policy itself, and that's just a policy. It's purely voluntary, I don't see how a voluntary policy counts as a significant barrier. A barrier, yes, but significant?
As for using MS-branded tools only, that's irrelevant, as the ability to run subversion servers on windows doesn't do anything to that barrier. Perhaps you didn't read the article?
I wrote the article. My reasoning goes something like this:
The CVS server, in my experience, doesn't run very well on Windows. Last time I tried CVSNT, it hung randomly whilst importing 200 megabyte source trees. I threw the same job at Subversion 0.30.0 (six months ago) and it worked like a charm. I conclude from this and previous experience that a CVS server is better off on Unix.
Subversion servers work great on Windows. It's the same source code, packaged as Windows binaries and released by the Subversion development team. Thanks largely to the Apache Portable Runtime (APR), Windows isn't a second-class hosting platform for Subversion.
There are plenty of "Windows only" shops, for a variety of reasons (experience, training, policy, sunk costs, inertia). Suggesting such shops should not be Windows only is kinda silly -- they just are, I often have to live with it when working on a project. Introducing Subversion to an organisation like that is as simple as finding an under utilised desktop and installing a Subversion server.
Getting a Subversion server up on a Unix machine is often a lot of work, because those machines tend to (not always, sure) have more red-tape surrounding them. Installing a random server isn't many admins cup of tea.
I conclude that having Windows fully supported as a first-class server platform for Subversion significantly lowers the barrier for entry for someone introducing Subversion to an enterprise. From a personal point of view, it also makes it easier for me to run a Subversion server on a laptop, where I'm running Windows.
Perforce used to use BDB, yes, but around 18 months ago they switched to a home-grown C++ DB of some sorts. Doing so required that it perform a dump/reload cycle (just like Subversion does when a major database upgrade is required -- think "maybe 2.0 and a long way off" in Subversion's case). This is yet another Subversion-is-like-Perforce moment where I get nice fuzzy feelings about Subversion. Perforce is database backed, with plaintext dump files, repository-wide revision numbers, cheap branches, and I still think it's the best system I've used. It's not free, of course...
Yep, Subversion comes with a conversion script, cvs2svn, which is under very active development right now. It's not quite so wonderful at converting CVS repositories with complicated branches, so you'll want to double-check the conversion, but lots of people are reporting success converting huge multi-gig repositories over to Subversion.
The Subversion book mentions that you need to set the umask, something that svnserve doesn't do automatically. It was discussed on the dev list, but dropped because it was felt that setting a umask was an access-dependent thing to do, and as such should be left to the repository administrator.
Using Subversion when logged in as root, and then as another user, is not going to work using file:// access to your repository, precisely because permissions get screwed up. Using svn+ssh:// without setting up your groups and permissions correctly will also result in a wedged repository. The Subversion book details these cases clearly.
The most common use-case for revision control is a networked repository. For this, you can use svnserve (easy to set up, works out-of-the-box), Apache (a bit more work, much more flexible) or svn+ssh (masses of security, you gotta get your permissions correct, more info in the book).
If you permissions get screwed, you don't lose or corrupt data. The repository just gets "wedged" and can be fixed using "svnadmin recover".
Subversion doesn't work just like CVS, it's masses better. People who are doing serious work with Subversion like it just fine. Don't confuse your misuse of a tool with the tool not working. Should Subversion fail more gracefully when permissions aren't set up right? Probably, yes -- but your use case is not the most common, and fixing it relies on fixing BerkeleyDB as well.
I've used Subversion on a major project, and was doing so with version 0.30 (about six months old now). We have around 11,000 files in source control, with about 2,000 changes being committed every week. The repository on the server is around 600MB, a checked out working copy runs to about 200MB. The server was on crappy desktop hardware running Linux (RedHat, but the flavour doesn't really matter) and performed admirably.
Since 0.30 there has been a major performance push, bringing Subversion operations close to CVS in terms of speed, and that's over a LAN. If you're using a lower bandwidth link, Subversion's efficient handling of networking (bidirectional diffs, offline diff, revert and status) will really help.
Sorry Eric, I think you're confused at least a little bit:
svn+ssh uses svnserve, but runs it as the user authenticated via ssh. svnserve running as a daemon references a password file containing username/password combinations -- you don't need a separate Unix user for each Subversion user. In this mode, svnserve is the only process accessing the repository, and only does it as one Unix user (whoever you started the svnserve process as).
svn+ssh requires all the Unix users that authenticate through ssh to be in the same group, and also requires some other magic to work. Maybe you got that magic wrong. When a permission problem occurs, your repository often needs to be "recovered" in order to fix it. Subversion's "svnadmin recover" can be used in these (usually rare) cases.
If you're still having problems do try posting to the users list: users@subversion.tigris.org.
If you use Apache to network your Subversion repository, you can leverage all of the access control mechanisms that Apache already provides. Basically you can do per-directory access control for Subversion in the same way you'd do it for standard directories on a website.
Using Apache also allows you to leverage SSL, wire-compression, etc, etc, that the basic svnserve server doesn't support. svnserve is still a good starting point for most organisations however -- over a LAN where you don't need encrypted traffic and basic username/password authentication will do.
Subversion implements branching and tagging as copy operations, hence they're all fast "cheap" copies. By convention, you don't commit changes to a tag, which is just a directory. It's possible to actually disallow changes to a tagged directory to people can't accidentally change a tag, of course.
I'm one of the XML Script developers, and it looks like today is the day for bug reports!
We're not sure why the URL retrieval isn't working (it's another library that does this for us, so we'll have to look into it further) but can you send us a bug report on the CGI thing? support@xmlscript.org is your best bet.
We know the documentation isn't the best in the world, and we have been working on it lots for v1.1 (which you should expect to see later this week). Thanks for the feedback.
As far as I know PGP is a DES encrypted message (40 significant bits in the key) with a randomly chosen key.
This isn't quite correct -- PGP uses the RSA public key crypto system (the one with the large prime numbers as keys, which the article was originally about) to encrypt a session key. The session key can be any length you like, and used for any symmetric crypto algorithm you want.
Whilst it's perfectly possible that PGP uses 40-bit DES, I know my version uses 128-bit IDEA. The reason it works like this is because RSA is very slow compared to symmetric cyphers like 3DES, Blowfish and IDEA.
You're correct when you say that compressing a message before sending it increases the difficulty of breaking it -- PGP does this automatically unless you tell it not to. Try PGP'ing an uncompressed text file, and you'll find that the ciphertext is smaller than the plaintext.
RC4-128 is based on a symmetric key system (where you have one key for encrypt/decrypt) whereas the cryptosystems the article is referring to are asymmetric (you have a private key and a public key).
For the symmetric systems, brute force checking of the whole keyspace is the only way to crack them. That means checking all of the 2^128 (lots!) possible keys. Asymmetric key systems are vulnerable to factoring attacks, as they make use of really big prime numbers to protect data.
For everyone not in the US (your export laws suck, people!) check out Fortify.Net to upgrade Netscape to 128-bit crypto.
The class of P-hard problems are soluble in polynomial time (for example n^3+2n^2 where n is the length of the input) by a deterministic Turing machine.
The class of NP-hard problems are soluble in polynomial time on a non-deterministic Turing machine. A nondeterministic machine will explore many possible solutions in parallel.
You can simulate a NDTM on a DTM with an exponential time penalty. A proof of P =? NP would presumably show us how to do this simulation without the massive time penalty. It's still an open question whether P = NP, but I wouldn't put any money on it being proved either way in the forseeable future.
Slashdot Mirror
TortoiseSVN is an excellent front-end, and there are a bunch of IDE plugins for integration with things like Eclipse, IntelliJ, Visual Studio...
http://tortoisesvn.tigris.org/
That's fine, and if it's working for you you don't need to change it, but personally I find it hard to remember that in version 1.15 I added a new table and that branched version 1.2.4.15 corresponds to the current production code.
In Subversion you'd use symbolically named tags, which are copies of directory trees, in order to remember that kind of thing. So you might have a bunch of files in your repository corresponding to your released software, in directoryIn your example a single revision number is useful because a change to SQL code usually involves a change to other code. For example, if you rename a column you'll need to change application code that accesses that column. If you commit all these changes in one go, logically grouping them together, it makes things a lot clearer when reviewing changes later on. Once you have changes grouped together as a unit you can move them around, apply them to other branches, or even back them out if they don't work.
Grouping changes like this together probably also implies some stuff like having database people sit with programmers and pair on their changes, but I'll avoid going off the deep-end and evangelising XP too much...
Yh im typng wth tre fngers nw.
The book does discuss the differences between the per-file (CVS) and repository-wide (Subversion) numbering schemes, although the conclusion is that the differences don't matter that much.
Basically if you're using version numbers on files to figure out "how much has changed recently" you should be probably looking at the log/history instead. Even if a file in CVS has only been incremented one revision point, the change could actually have altered every line in the file. The numbers don't really give you concrete information about how much "churn" is going on in the code.
I'd recommend using decent log messages and keeping commits small and specific over using revision numbers to figure out what's changed.
When I was initially getting involved with Subversion I found that most of its features reminded me a lot of Perforce. The repository-wide revision numbers, database backend, and general "feel" of Subversion is very similar to Perforce.
I think Perforce is better than Subversion if you're doing a lot of branching -- the merge point tracking that Perforce performs is really well implemented and saves you from a lot of manual tracking. Overall though if you're looking for a free alternative to Perforce I'd highly recommend Subversion
If cost isn't the issue, then what is? For MS-only shops, the issue is the MS-only policy itself, and that's just a policy. It's purely voluntary, I don't see how a voluntary policy counts as a significant barrier. A barrier, yes, but significant?
As for using MS-branded tools only, that's irrelevant, as the ability to run subversion servers on windows doesn't do anything to that barrier. Perhaps you didn't read the article?
I wrote the article. My reasoning goes something like this:
I conclude that having Windows fully supported as a first-class server platform for Subversion significantly lowers the barrier for entry for someone introducing Subversion to an enterprise. From a personal point of view, it also makes it easier for me to run a Subversion server on a laptop, where I'm running Windows.
Perforce used to use BDB, yes, but around 18 months ago they switched to a home-grown C++ DB of some sorts. Doing so required that it perform a dump/reload cycle (just like Subversion does when a major database upgrade is required -- think "maybe 2.0 and a long way off" in Subversion's case). This is yet another Subversion-is-like-Perforce moment where I get nice fuzzy feelings about Subversion. Perforce is database backed, with plaintext dump files, repository-wide revision numbers, cheap branches, and I still think it's the best system I've used. It's not free, of course...
Yep, Subversion comes with a conversion script, cvs2svn, which is under very active development right now. It's not quite so wonderful at converting CVS repositories with complicated branches, so you'll want to double-check the conversion, but lots of people are reporting success converting huge multi-gig repositories over to Subversion.
The Subversion book mentions that you need to set the umask, something that svnserve doesn't do automatically. It was discussed on the dev list, but dropped because it was felt that setting a umask was an access-dependent thing to do, and as such should be left to the repository administrator.
More info at http://svnbook.red-bean.com/html-chunk/ch06s05.htm l
Using Subversion when logged in as root, and then as another user, is not going to work using file:// access to your repository, precisely because permissions get screwed up. Using svn+ssh:// without setting up your groups and permissions correctly will also result in a wedged repository. The Subversion book details these cases clearly.
The most common use-case for revision control is a networked repository. For this, you can use svnserve (easy to set up, works out-of-the-box), Apache (a bit more work, much more flexible) or svn+ssh (masses of security, you gotta get your permissions correct, more info in the book).
If you permissions get screwed, you don't lose or corrupt data. The repository just gets "wedged" and can be fixed using "svnadmin recover".
Subversion doesn't work just like CVS, it's masses better. People who are doing serious work with Subversion like it just fine. Don't confuse your misuse of a tool with the tool not working. Should Subversion fail more gracefully when permissions aren't set up right? Probably, yes -- but your use case is not the most common, and fixing it relies on fixing BerkeleyDB as well.
I've used Subversion on a major project, and was doing so with version 0.30 (about six months old now). We have around 11,000 files in source control, with about 2,000 changes being committed every week. The repository on the server is around 600MB, a checked out working copy runs to about 200MB. The server was on crappy desktop hardware running Linux (RedHat, but the flavour doesn't really matter) and performed admirably.
Since 0.30 there has been a major performance push, bringing Subversion operations close to CVS in terms of speed, and that's over a LAN. If you're using a lower bandwidth link, Subversion's efficient handling of networking (bidirectional diffs, offline diff, revert and status) will really help.
Sorry Eric, I think you're confused at least a little bit:
svn+ssh uses svnserve, but runs it as the user authenticated via ssh. svnserve running as a daemon references a password file containing username/password combinations -- you don't need a separate Unix user for each Subversion user. In this mode, svnserve is the only process accessing the repository, and only does it as one Unix user (whoever you started the svnserve process as).
svn+ssh requires all the Unix users that authenticate through ssh to be in the same group, and also requires some other magic to work. Maybe you got that magic wrong. When a permission problem occurs, your repository often needs to be "recovered" in order to fix it. Subversion's "svnadmin recover" can be used in these (usually rare) cases.
If you're still having problems do try posting to the users list: users@subversion.tigris.org.
If you use Apache to network your Subversion repository, you can leverage all of the access control mechanisms that Apache already provides. Basically you can do per-directory access control for Subversion in the same way you'd do it for standard directories on a website.
Using Apache also allows you to leverage SSL, wire-compression, etc, etc, that the basic svnserve server doesn't support. svnserve is still a good starting point for most organisations however -- over a LAN where you don't need encrypted traffic and basic username/password authentication will do.
More info in the book, as always: http://svnbook.red-bean.com/html-chunk/ch06.html#s vn-ch-6-sect-1
Subversion implements branching and tagging as copy operations, hence they're all fast "cheap" copies. By convention, you don't commit changes to a tag, which is just a directory. It's possible to actually disallow changes to a tagged directory to people can't accidentally change a tag, of course.
So if you have your project at
svn://myserver/projects/myProject/trunk
you can create a tag by doing
svn cp svn://myserver/projects/myProject/trunk svn://myserver/projects/myProject/tags/1.0.0/
We're not sure why the URL retrieval isn't working (it's another library that does this for us, so we'll have to look into it further) but can you send us a bug report on the CGI thing? support@xmlscript.org is your best bet.
We know the documentation isn't the best in the world, and we have been working on it lots for v1.1 (which you should expect to see later this week). Thanks for the feedback.
This isn't quite correct -- PGP uses the RSA public key crypto system (the one with the large prime numbers as keys, which the article was originally about) to encrypt a session key. The session key can be any length you like, and used for any symmetric crypto algorithm you want.
Whilst it's perfectly possible that PGP uses 40-bit DES, I know my version uses 128-bit IDEA. The reason it works like this is because RSA is very slow compared to symmetric cyphers like 3DES, Blowfish and IDEA.
You're correct when you say that compressing a message before sending it increases the difficulty of breaking it -- PGP does this automatically unless you tell it not to. Try PGP'ing an uncompressed text file, and you'll find that the ciphertext is smaller than the plaintext.
For the symmetric systems, brute force checking of the whole keyspace is the only way to crack them. That means checking all of the 2^128 (lots!) possible keys. Asymmetric key systems are vulnerable to factoring attacks, as they make use of really big prime numbers to protect data.
For everyone not in the US (your export laws suck, people!) check out Fortify.Net to upgrade Netscape to 128-bit crypto.
The class of NP-hard problems are soluble in polynomial time on a non-deterministic Turing machine. A nondeterministic machine will explore many possible solutions in parallel.
You can simulate a NDTM on a DTM with an exponential time penalty. A proof of P =? NP would presumably show us how to do this simulation without the massive time penalty. It's still an open question whether P = NP, but I wouldn't put any money on it being proved either way in the forseeable future.