On Nov 7, 2005, at 23:43, Jesse Erlbaum wrote:
>>> CLIENT_A/branches/
>>> CLIENT_A/tags/
>>> CLIENT_A/PROJ_1/
>>> CLIENT_A/PROJ_2/
>>> CLIENT_A/PROJ_3/
>>> CLIENT_A/PROJ_4/
>>> CLIENT_A/PROJ_5/
>>>
>>> Notes:
>>> * No "trunk" directory. Seemed redundant. Whatever is in a
>>> "PROJ_X"
>>> directory is the latest version -- aka, "trunk" (aka "HEAD").
>>> * No project dir branches and tags. To tag or branch I'll just
>>> copy
>>> to the client-level directories.
>>>
>>> The goal is to allow the projects to be "semi independent". A
>>> user can
>>> work on just one, or on all of them. Conceivably, you could tag/
>>> branch
>>> all the projects at once, or just one project. It seemed to be
>>> the best
>>> of all worlds.
>>
>> Unless you want to check out the whole repos, you will not be able to
>> get atomic commits across projects, since svn co -N is currently
>> broken.
>
> If I understand what you're saying here, because there is no "trunk/"
> directory it won't be possible to check out all the projects at
> once, or
> to commit changes to all at once. Is that right?
>
> Couldn't I just check out the CLIENT_A directory (including the
> tags and
> branches directories)?
Sure, you can check out the entire repository, and you'll get a
complete copy of every tag and every branch you've made. It'll take
time to transmit over the network, and it'll take space on your local
disk. The working copy for one of our big projects is 100MB on disk,
and we currently have 7 branches and 50 tags in the repository, so if
we checked out the whole thing that would be over 5GB, which is
silly, and that's just one project. Sooner or later, depending on how
big your projects are and how many tags and branches you make, you're
going to wish for another solution that allows you to get the current
development version of every project easily—assuming it is important
to you to be able to get all projects at once, which you implied. And
the solution is a directory commonly known as trunk.
Using a single directory for branches and tags would probably work,
but may get unwieldy over time. Assuming you discipline yourself in
naming your branches things like PROJ_1_1.0 and your tags things like
PROJ_1_1.0.5 then you can still at some point later answer the
question "what branches (or tags) exist for PROJ_1?" but the question
would be easier to answer if there were a single URL ($URL/to/
CLIENT_A/branches/PROJ_1 for example).
There's also the question—which a project subdirectory in the
branches directory doesn't necessarily solve—of how you intend to
name the branches which contain, say, PROJ_1 and PROJ_3. Presumably
you will decree that the combination of PROJ_1 and PROJ_3 is to be
known as FOO, and then you will have a branch FOO_2.5 which contains
directories PROJ_1 and PROJ_3. And presumably the next day you will
decree that the combination PROJ_1 and PROJ_4 is known as BAR, and
then you'll make a branch BAR_1.0 with subdirectories PROJ_1 and PROJ_4.
If PROJ_1 and PROJ_3 will always be used together, and PROJ_1 will
never be branched in combination with a project other than PROJ_3 and
vice versa, then it would be clearer to indicate that at the trunk
level too with an intermediate FOO directory.
>> Also hand building branches like you are talking about can be
>> disk intensive since they'll need to be done client-side, unless you
>> feel like using some scripting tools to combine multiple commands
>> into a single transaction (for which there are tools).
>
> Couldn't I just copy the files in my WC, and commit all at once?
If you had a working copy of the entire repository as you suggest,
then yes, you could do that.
On Nov 8, 2005, at 00:29, Jesse Erlbaum wrote:
>>>> But in the end, it is whatever fits your workflow best. Work is
>>>> currently underway to fix non-recursive checkouts, so that may
>>>> not be an issue for long.
>>>
>>> How do you see broken non-recursive checkouts causing a problem
>>> in the
>>> scheme I'm describing?
>>
>> If you could do a non-recursive checkout, you could check out just
>> the projects you were working on, without the branches or tags dir.
>> But doing this now leads to broken behavior, so you have to check out
>> everything.
>
> Wouldn't this work?:
>
> $ svn checkout /path/to/CLIENT_A/PROJ_3 PROJ_3
>
> In my way of thinking, this is a recursive checkout -- just of a
> directory of the repository. What is broken about this?
That would work, if you just want to work on PROJ_3. You are correct;
that is a recursive checkout of a subdirectory of the repository.
Nothing is broken about that.
But if you want to work on multiple projects at the same time, and
branch them together, as you say you do, then this won't help you.
The non-recursive option Joshua is talking about is that you are
supposed to be able to say "give me the root of the repository, but
only give me the PROJ_1 and PROJ_3 directories, nothing else." It
would let you avoid the problem of downloading and storing every
branch and every tag. The option is broken, however, and leads to
unexpected behavior, so you shouldn't try to use it. Instead, you
should restructure your repository to enable you to do the kinds of
work you want to be able to do, knowing that at present you can only
checkout an entire directory. Using a trunk directory as suggested,
you would still have to download and store every project, but at
least you wouldn't have to have all branches and tags as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 8 13:14:20 2005