Mikael Jansson (mailing lists) wrote: > [...] > ~/tic/workspace/dundermusen/.p4env > [...]
This is even easier with svn because you do not have to do anything at all. The first checkout stores the needed information.
- files are read-only, must "p4 edit" to make writable
That's because the Perforce server saves the state of all clients connecting to the server, which means all operations involving the server will be much faster (sync, submit).
Also means it doesn't leave cruft behind (CVSRoot, SVN, ...) in your checked-out files.
That is not nice, but it is not really bad either.
subversion: + not much new to learn (just a better CVS) + open source + already ported + atomic
Also, BeClan uses SVN, so there's already some momentum there.
Now, as both Subversion and Perforce require a server we still have the problem of where to run it. It seems there are services already providing SVN access, so that's good. I'd still prefer Perforce, however; has been a lot faster to use and like I said doesn't put their folders everywhere.
I am not unhappy with cvs speed and please let me explain my decision: At first I did not even want to look at svn because it known as "just a better cvs". I wanted to have something revolutionary new, but that is not available, yet. So, in my search I read some texts on subversion and now I realized it is cool!
You wanted a real comparion. Here it is (for the two last SCM systems to-be-considered [p4 and svn]):
We want to do the following: 1. add 2. remove 3. edit 4. move (rename) 5. tag 6. branch
We also want simplicity. Both, p4 and svn are good. But IMHO, svn is even a little bit easier to get started with: svn co <repository> vs.: p4 client <edit configuration file> p4 sync
Also, we will need good branching. p4 has better merging and tracking, but svn is easier to use, IMHO. Both systems are based around a brach=copy principle (in svn it is even called "svn copy"). I want to have a "hacking" branch for experimental stuff that should not clobber our development branch. When I came to the net-team I was told to start in the "tests" tree and code around until I have something that compiles and then move it to the "src" tree. Everything starts in the "tests" tree. This is bad because: 1. "tests" has different compilation flags than "src" 2. other devs must download experimental code that is not interesting to them 3. everybody must compile it (and experimental code is known to often not build properly)
We can do better: Say, the net-team starts porting the new BSD netstack. For this we must replace the "network" kernel modules with the new stack. With "svn switch" I can tell svn to replace that folder's contents with the hacking branch's new_bsd folder (but only in my personal working-copy). The same can be done with "p4 client" and setting the client view to map that folder to a different one. Now my repository will behave as if I replaced that folder by hand, but other people will not notice anything and build the old netstack. The rest of the repository is not affected. When we are finished we can switch back to the default mapping and actually replace that folder with the new netstack. Additionally, I would like to use the "hacking" branch to commit every change of my PPP code (even if it does not compile). This would allow me to revert any changes at any time and start at an earlier (hacking) point. The development branch would behave like now: a central for code that compiles and in which people commit less often, but more changes at once. I want to commit when the coding-day ends to freeze and backup my work. (This is just what I want ;). With p4 this all is possible, too, but with svn it is slightly simpler and the "svn switch" command is much nicer than editing a text file with "p4 client".
And we do not have to run our own svn server because there are free services with people who know how to maintain everything. If we want to we could make daily backups on our servers in order to not risk losing our work, but their servers are probably much more secure and stable than ours. And we have free resources (and more money?) for other things.
Oh, and did I mention that svn supports meta-data (thus, mime-types, too)? This is something p4 cannot give us, or am I wrong?
Subversion is very nice! Let's use it. It has its flaws, but it seems to fit our needs better than p4 (if you ask me). Vote svn for president! ;)
Bye, Waldemar