I hope I didn't leave you with the impression that you can't "label"
in Subversion.
When I first saw Subversion back in release 1.2, I realized
immediately an issue with tags (labels), and I rewrote the old
pre-commit access control hook to include a special "add-only"
permission.
That way, I could say that anything on the tags subdirectory is
add-only. You can add to that directory, but not modify anything on
that directory. This allowed users to create tags although they
couldn't edit them. Not as good as most CM systems that allow for tags
which can be locked and unlocked by the creator, but still pretty
good.
My hook also worked in such a way that you could specify a <USER>
directory. That is, a directory named after the user. I set it up, so
only that user had read/write permissions on that tag directory. Users
could create a tag and modify that tag, but no one else could modify
or create a tag in that user's directory. This solved the lock/unlock
issue.
As for creating a branch from a tag, you can easily do that in two
ways in Subversion. The first is the easiest: Simply copy the tag
directory to a branch directory. The second way (and my preference) is
to find the release number and branch used by that tag, and then do a
copy from that release and branch.
So, Subversion isn't crippled due to the lack of a true tag/label. It
does make things a bit trickier to use, but nothing that can't be
accomplished without too much difficulty.
========================================
I believe it is very interesting to compare P4 and Subversion because
there are very many similarities between the two:
* Both version whole archives (Perforce uses changelist IDs for this)
* Both use what Perforce calls "interfile branching" for doing their branching
* Both use server side hooks for doing specific operations.
However, there are some difference that can either be an advantage to
Subversion or Perforce:
* Perforce requires a "client" to be made before users are allowed to
checkout their code while Subversion simply allows a "checkout" right
from the directory. No need for clients or client maintenance. This
makes using Subversion simpler in many ways. Developers always stumble
over the client concept and I usually am forced to make default
clients for them.
However, the Perforce client adds quite a bit of power. You can easily
do partial checkouts which can be quite complex in Subversion. You can
also setup your client working directory in ways that are not
reflected in the source repository. For example, in our code we have
hundreds of HTML and JPG help files inside a directory in our modules.
Developers hate checking out this directory, but there's no easy fix
in Subversion. You can easily tell a Perforce client to skip this
directory. Another issue is when different clients have different
files. In Perforce, you can write a client to map these changes over
your working directory. You can't do that in Subversion.
* Perforce requires you to mark a file for editing before you edit it.
This isn't the same as a checkout in most revision control systems
because marking a file for edit doesn't lock it. This confuses the
heck out of developers and many developers use to CVS or Subversion
balk at the fact you have to "checkout files like you do in RCS"
before you edit them.
This causes a few issues: It adds another complexity to using
Perforce. Also marking a file as edit means Perforce has to talk to
the server. A problem if you are working disconnected from the server
and working remotely. Not that you can't do that in Perforce, but it
is a headache. In Subversion, you don't have to communicate with the
server until you commit your files.
But, there is a reason for Perforce's madness. By marking a file for
edit, you can let others who want to edit this file that you are
editing it -- even though it isn't really locked. It gives developers
a heads up that there's going to be a merge down the road. It also
allows you to specify an alternate changelist which can be used to
prevent you from checking in files that you don't want to change. For
example, I might want to modify the default configuration file, but
not check in those changes. I can mark the configuration file for
editing and put it in another changelist instead of my default.
Committing my changes with "p4 submit" won't commit the configuration
changes.
* One of the features I like about Subversion are the easy to use
properties. This substitutes much of what Perforce does with their
more complex file types. I am mixed about the way Perforce handles
line endings. In Perforce line endings are client dependent while in
Subversion, they are specified on the property svn:eol-style. Both
have their advantages and disadvantages.
* Perforce has a built in security which is a lot more flexible than
Subversion which depends upon the OS and server security features. In
Perforce, the security is set in a single location. However,
Subversion does have the advantage that because the security is
handled by the OS, it is possible to easily incorporate your current
security features into Subversion. Therefore, you could end up with a
setup where you no longer are responsible for licensing and
permissioning issues.
Personally, I like Perforce, but it can be hard to justify the
$900/user price tag. For example, at my current position, we'd have to
spend around $45,000 to $50,000 for initial licensing which is quite a
bite out or our software budget.
--
David Weintraub
qazwart_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-11-17 18:29:45 CET