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
