You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by baz themail <ba...@gmail.com> on 2008/09/25 17:46:46 UTC
Is there a repo/workspace mapping in SVN just like Perforce's client spec?
Hi,
Is there a repo/workspace mapping in SVN just like Perforce's client spec?
Is it common in SVN? What is the best practice or common thing to do in SVN?
Thanks.
A.
Re: Ignoring tags and branches
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Ignoring tags and branches
Trevor Harmon wrote on 26 Sep 2008, 11:43, at least in part:
> Our source code repository has an ever-growing number of tags and
> branches. This really slows things down because when I do a checkout,
> the entire history of tags and branches are checked out. Difference,
> status, and search operations are also slowed down because they
> consider the tag and branch directories, even though I'm always
> working on the trunk.
>
> Is there some way to filter checkouts, or perhaps modify the working
> copy after a checkout, so that tags and branches are ignored? For
> example, if the repository looks like this:
>
> company/project1/tags
> company/project1/branches
> company/project1/trunk
> company/project2/tags
> company/project2/branches
> company/project2/trunk
I suppose it is too late to revise the structure:
company/trunk/project1
company/trunk/project2
company/branches/project1
company/branches/project2
company/tags/project1
company/tags/project2
Which has its downsides as well of course.
Jan Hendrik
---------------------------------------
Freedom quote:
Socialism in general has a record of failure so blatant
that only an intellectual could ignore or evade it.
-- Thomas Sowell
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there a repo/workspace mapping in SVN just like Perforce's client spec?
Posted by David Weintraub <qa...@gmail.com>.
On Thu, Oct 2, 2008 at 12:38 AM, Blair Zajac <bl...@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@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there a repo/workspace mapping in SVN just like Perforce's
client spec?
Posted by Blair Zajac <bl...@orcaware.com>.
David Weintraub wrote:
> Now, when I checkout project A, I automatically get a sub directory
> B-lib with projectB underneath it, and there is no need for a client
> spec.
>
> All other client mappings that Perforce can do cannot be done in Subversion.
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?
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Ignoring tags and branches
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Trevor Harmon [mailto:trevor@vocaro.com]
> Sent: Friday, September 26, 2008 11:43 AM
> To: Subversion Users
> Subject: Ignoring tags and branches
>
> Our source code repository has an ever-growing number of tags and
> branches. This really slows things down because when I do a checkout,
> the entire history of tags and branches are checked out. Difference,
> status, and search operations are also slowed down because they
> consider the tag and branch directories, even though I'm always
> working on the trunk.
>
> Is there some way to filter checkouts, or perhaps modify the working
> copy after a checkout, so that tags and branches are ignored? For
> example, if the repository looks like this:
>
> company/project1/tags
> company/project1/branches
> company/project1/trunk
> company/project2/tags
> company/project2/branches
> company/project2/trunk
>
> I'd want the working copy to look like this:
>
> company/project1/trunk
> company/project2/trunk
>
Plan B: Use -N [--non-recursive] : operate on single directory
only
svn co -N company
cd company
svn update -N project1
svn update -N project1/trunk
svn update -N project2/trunk
svn update -N project3/trunk
Obviously you would want to script it. And you'll have to be careful
about running 'svn update' at the company or project level or you'll
wind up downloading everything (but that's normally a self-correcting
training issue.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignoring tags and branches
Posted by "Clark S. Cox III" <cl...@apple.com>.
On Sep 26, 2008, at 8:55 AM, Trevor Harmon wrote:
> On Sep 26, 2008, at 11:46 AM, Hilco Wijbenga wrote:
>
>> So why don't you just check out trunk instead of everything?
>
> Because my repository has 50 different projects, not just two, and I
> work on any number of them from time to time. Therefore I have to
> check out everything.
>
> I guess I could do 50 separate "svn co" commands, but I was hoping
> for a better solution.
You could probably do something like:
svn co --depth immediates <url> <workingcopy>
cd <workingcopy>
for subdir in (*); do
svn update --set-depth infinity ${subdir}/trunk
done
--
Clark S. Cox III
clark.cox@apple.com
Re: Ignoring tags and branches
Posted by Andy Levy <an...@gmail.com>.
On Fri, Sep 26, 2008 at 11:55, Trevor Harmon <tr...@vocaro.com> wrote:
> On Sep 26, 2008, at 11:46 AM, Hilco Wijbenga wrote:
>
>> So why don't you just check out trunk instead of everything?
>
> Because my repository has 50 different projects, not just two, and I work on
> any number of them from time to time. Therefore I have to check out
> everything.
>
> I guess I could do 50 separate "svn co" commands, but I was hoping for a
> better solution.
So you've checked out the entire repository from the root?
I agree with Hilco, only check out what you really need to work on.
You normally shouldn't need to have tags checked out at all, and only
the branch(es) you're currently working on.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignoring tags and branches
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 26, 2008, at 10:55, Trevor Harmon wrote:
> On Sep 26, 2008, at 11:46 AM, Hilco Wijbenga wrote:
>
>> So why don't you just check out trunk instead of everything?
>
> Because my repository has 50 different projects, not just two, and
> I work on any number of them from time to time. Therefore I have to
> check out everything.
>
> I guess I could do 50 separate "svn co" commands, but I was hoping
> for a better solution.
If you really need to work on all 50 projects, then the correct
solution is to issue 50 separate "svn co" commands.
You don't need to check everything out again, if you already have a
working copy of everything. Just move each trunk that you want to
save outside of the big working copy. Then delete the big working
copy. e.g. if you have this working copy on your disk now:
On Sep 26, 2008, at 10:43, Trevor Harmon wrote:
> company/project1/tags
> company/project1/branches
> company/project1/trunk
> company/project2/tags
> company/project2/branches
> company/project2/trunk
Then do this:
mv company company-old
mkdir company
mv company-old/project1/trunk company/project1-trunk
mv company-old/project2/trunk company/project2-trunk
rm -rf company-old
Now you have separate working copies in "company" for each project.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignoring tags and branches
Posted by John Allen <jo...@dublinux.net>.
Hilco Wijbenga wrote:
> On Fri, Sep 26, 2008 at 08:55, Trevor Harmon <tr...@vocaro.com> wrote:
>
>> On Sep 26, 2008, at 11:46 AM, Hilco Wijbenga wrote:
>>
>>
>>> So why don't you just check out trunk instead of everything?
>>>
>> Because my repository has 50 different projects, not just two, and I work on
>> any number of them from time to time. Therefore I have to check out
>> everything.
>>
>> I guess I could do 50 separate "svn co" commands, but I was hoping for a
>> better solution.
>>
>
> Then create a project with svn:externals to all the trunks you need.
> Or just write a script like Clark suggested.
>
> Mind you, I doubt you work on all 50 at the same time. So you would
> svn co only a few projects at a time. That doesn't sound too bad. In
>
Hell I'm working on 60 different projects concurrently right now.
And yes I checked them out independently.
> any case, it takes *far* less time to type svn co a few times than to
> wait for an entire repository to download. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignoring tags and branches
Posted by Hilco Wijbenga <hi...@gmail.com>.
On Fri, Sep 26, 2008 at 08:55, Trevor Harmon <tr...@vocaro.com> wrote:
> On Sep 26, 2008, at 11:46 AM, Hilco Wijbenga wrote:
>
>> So why don't you just check out trunk instead of everything?
>
> Because my repository has 50 different projects, not just two, and I work on
> any number of them from time to time. Therefore I have to check out
> everything.
>
> I guess I could do 50 separate "svn co" commands, but I was hoping for a
> better solution.
Then create a project with svn:externals to all the trunks you need.
Or just write a script like Clark suggested.
Mind you, I doubt you work on all 50 at the same time. So you would
svn co only a few projects at a time. That doesn't sound too bad. In
any case, it takes *far* less time to type svn co a few times than to
wait for an entire repository to download. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignoring tags and branches
Posted by Trevor Harmon <tr...@vocaro.com>.
On Sep 26, 2008, at 11:46 AM, Hilco Wijbenga wrote:
> So why don't you just check out trunk instead of everything?
Because my repository has 50 different projects, not just two, and I
work on any number of them from time to time. Therefore I have to
check out everything.
I guess I could do 50 separate "svn co" commands, but I was hoping for
a better solution.
Trevor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignoring tags and branches
Posted by Hilco Wijbenga <hi...@gmail.com>.
On Fri, Sep 26, 2008 at 08:43, Trevor Harmon <tr...@vocaro.com> wrote:
> Our source code repository has an ever-growing number of tags and branches.
> This really slows things down because when I do a checkout, the entire
> history of tags and branches are checked out. Difference, status, and search
> operations are also slowed down because they consider the tag and branch
> directories, even though I'm always working on the trunk.
So why don't you just check out trunk instead of everything?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignoring tags and branches
Posted by David Weintraub <qa...@gmail.com>.
Are you using Subversion 1.5 or greater?
You can use the --depth=immediates switch to just checkout the
directories for trunk, branches, and tags:
$ svn co --depth=immediates svn://localhost/company
This will checkout all fifty projects, but just the project directory
and nothing else.
Then you can do something like this:
$ cd company
$ svn update */trunk
That should checkout all the trunks without the branches and tags.
--
David Weintraub
qazwart@gmail.com
On Fri, Sep 26, 2008 at 11:43 AM, Trevor Harmon <tr...@vocaro.com> wrote:
> Our source code repository has an ever-growing number of tags and branches.
> This really slows things down because when I do a checkout, the entire
> history of tags and branches are checked out. Difference, status, and search
> operations are also slowed down because they consider the tag and branch
> directories, even though I'm always working on the trunk.
>
> Is there some way to filter checkouts, or perhaps modify the working copy
> after a checkout, so that tags and branches are ignored? For example, if the
> repository looks like this:
>
> company/project1/tags
> company/project1/branches
> company/project1/trunk
> company/project2/tags
> company/project2/branches
> company/project2/trunk
>
> I'd want the working copy to look like this:
>
> company/project1/trunk
> company/project2/trunk
>
> I'm aware of the svn:ignore property, but I don't think it applies here. For
> one thing, it would affect everyone. The filtering here should apply only to
> my working copy.
>
> Trevor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Ignoring tags and branches
Posted by Trevor Harmon <tr...@vocaro.com>.
Our source code repository has an ever-growing number of tags and
branches. This really slows things down because when I do a checkout,
the entire history of tags and branches are checked out. Difference,
status, and search operations are also slowed down because they
consider the tag and branch directories, even though I'm always
working on the trunk.
Is there some way to filter checkouts, or perhaps modify the working
copy after a checkout, so that tags and branches are ignored? For
example, if the repository looks like this:
company/project1/tags
company/project1/branches
company/project1/trunk
company/project2/tags
company/project2/branches
company/project2/trunk
I'd want the working copy to look like this:
company/project1/trunk
company/project2/trunk
I'm aware of the svn:ignore property, but I don't think it applies
here. For one thing, it would affect everyone. The filtering here
should apply only to my working copy.
Trevor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there a repo/workspace mapping in SVN just like Perforce's client spec?
Posted by David Weintraub <qa...@gmail.com>.
For those who never used Perforce. Let me explain what "BAZ" is talking about.
In Subversion (like CVS) when you do a checkout, you checkout that
module directly into a working directory, plus (by default) all
sub-modules just as they are stored in the repository. There is no
need to describe what you want before you get it.
Perforce is like Clearcase where you have to create a "client' before
you can do your checkout. In Subversion, you specify what you want to
checkout via the Subversion URL. In Perforce, you explain what you
want to checkout via the client specification.
So, checking out in Perforce is a two step process:
Step #1: Create a client explaining what you want to checkout.
Step #2: Do the checkout command with that client specification.
This makes the standard checkout in Perforce a bit less spontaneous,
but it does allow me to do something that you can't do in Subversion:
Specify what I want my working directory to look like once everything
is checked out. In Subversion, my working directory is mapped exactly
the way it is in my source repository. In Perforce, I can remap my
working client not to reflect my source repository.
For example, I might checkout a project that has hundreds of files of
help documents that I simply am not interested in. In Subversion, not
checking out those help documents without the rest of the project is
extremely difficult. In Perforce, I can map my workspace to check out
the entire project, but not checkout those help documents.
Another reason why I might want to remap my working directory is if
the project I checkout is dependent upon an external project. In
Perforce, I specify in my "client" that I want to checkout project
"A", and then checkout external project "B" as a sub-directory of
project "A".
So, BAZ, if this is the type of mapping you need to do, you do this by
using the Subversion property "svn:externals" on the main project to
map it to the external project. For example, in Perforce, my client
will look like this:
//deploy/projectA/MAIN/... //workspace/projectA/...
//deploy/projectB/MAIN/... //workspace/projectA/B-lib/...
In Subversion, I would do this by attaching the attribute
"svn:externals" to directory "projectA" with the following mapping:
B-lib http://svn/dev/projectB/trunk
Now, when I checkout project A, I automatically get a sub directory
B-lib with projectB underneath it, and there is no need for a client
spec.
All other client mappings that Perforce can do cannot be done in Subversion.
--
David Weintraub
qazwart@gmail.com
On Thu, Sep 25, 2008 at 1:46 PM, baz themail <ba...@gmail.com> wrote:
> Hi,
>
> Is there a repo/workspace mapping in SVN just like Perforce's client spec?
> Is it common in SVN? What is the best practice or common thing to do in SVN?
>
> Thanks.
>
> A.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there a repo/workspace mapping in SVN just like Perforce's
client spec?
Posted by "Robert P. J. Day" <rp...@crashcourse.ca>.
Quoting Andy Levy <an...@gmail.com>:
> On Thu, Sep 25, 2008 at 13:46, baz themail <ba...@gmail.com> wrote:
>> Hi,
>>
>> Is there a repo/workspace mapping in SVN just like Perforce's client spec?
>> Is it common in SVN? What is the best practice or common thing to do in SVN?
>
> For those of us who've never used Perforce, what does this "mapping" do?
>
> I'm guessing the answer is "no, there is no such feature" and "no,
> it's not common."
the only "mapping" that leaps to mind is what you get from "svn info".
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there a repo/workspace mapping in SVN just like Perforce's client spec?
Posted by Andy Levy <an...@gmail.com>.
On Thu, Sep 25, 2008 at 13:46, baz themail <ba...@gmail.com> wrote:
> Hi,
>
> Is there a repo/workspace mapping in SVN just like Perforce's client spec?
> Is it common in SVN? What is the best practice or common thing to do in SVN?
For those of us who've never used Perforce, what does this "mapping" do?
I'm guessing the answer is "no, there is no such feature" and "no,
it's not common."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org