Re: Is there a repo/workspace mapping in SVN just like Perforce's client spec?

On Thu, Oct 2, 2008 at 12:38 AM, Blair Zajac <blair_at_orcaware.com> wrote:
> I haven't used Perforce, but svn 1.6 will have file externals, does that
> allow it to have the other client mappings that Perforce does?

I don't really think Subversion ever can unless Subversion makes some
major changes in its infrastructure.

The full mapping of Perforce can be found here:
<http://perforce.com/perforce/doc.081/manuals/p4guide/02_config.html#1066090>

When you map a client working directory with Perforce, you specify
what you want to checkout from the repository on the left and how you
want to check it out on the right. The standard mapping is like this:

//depot/myproject/MAIN/... //workspace/...

In this case, I am checking out the MAIN branch of myproject to the
root of my workspace. Pretty much what Subversion does.

However, let's say I am modifying the source and HTML help files of my
project, but not the Microsoft Word documents. The HTML files are
embedded deeply in my source tree, but I really don't want to delve
into my source tree to work on the HTML files. What would be easier
for me to work is if my source tree and HTML help files were sibling
directories. I could do a mapping like this:

//depot/myproject/MAIN/src //workspace/src/...
-//depot/myproject/MAIN/....doc //workspace/....doc
//depot/myproject/MAIN/src/help/en/....html //workspace/help/....html

The first line is like the one above -- a direct mapping of repository
to my working directory. The second mapping (with the minus sign in
front) tells Perforce not to checkout my *.doc files. The third line
remaps the embedded HTML source files to a "help" directory that's
parallel to my "src" directory.

---
Here's another neat trick, and one which I've found very useful.
Imagine you have a standard project. (We'll call it "Foo".) This
project contains some configuration files that differ from client to
client. There might even be some customized source changes depending
upon the client too. To handle this, I keep a copy of all the client's
customized files in my repository under the "client" directory under
the client's name.
I have a client "Acme" and I need to produce a build specifically for
this client. I could have this mapping:
//depot/Foo/MAIN/...  //workspace/...
+//depot/clients/Acme/Foo/MAIN/... //workspace/...
This will give me all the files in Foo, but any files that Acme might
have that differ will overwrite the standard files found in project
Foo.
----
All this is nice and powerful, but it creates a lot of complexity.
First of all, before you can begin to checkout from Perforce, you need
to create a client that contains your mapping. This is true even
though 99.9% of the time, you are simply doing a direct repository
mapping to your working directory.
Perforce also has to track these clients. There has to be a database
that tracks clients, who owns them, and their mappings. That's more
complexity in the program. Plus, you now have to train your developers
how to use these mappings. And, you have developers create a client,
do a checkout, and then delete their working directory. In Subversion,
that's fine, but in Perforce, you still have a client mapping! Now,
the CM has to track who is using what mappings and making sure that
ghost mappings won't be causing any problems.
All of this for the 0.01% of the time when you might want your working
directory mapping to be somewhat different from your repository
layout.
By the way, Subversion's svn:externals property is superior to
Perforce's way of mapping. In Subversion, when I setup my
svn:externals, it is automatically mapped for anyone who does a
checkout. In Perforce, each user must manually map their client to do
the external mapping.
I recommend everyone to take a look at Perforce -- especially the
Subversion developers. You can use Perforce for free if you have fewer
than two users and less than five clients.
Perforce and Subversion share a lot of features (repository
revisioning, using directories to map branches, etc.) However, it is
very interesting to see the differences and the philosophy behind each
product.
--
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