You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by trans <tr...@gmail.com> on 2010/01/25 13:25:13 UTC
Keeping tags/ and branches/ in the "trunk"
Hi--
Is it possible to keep tags/ and branches/ in the trunk/ so as not to
have to differentiate these three at the top of a repository.
In other words, instead of:
branches/
BRANCH_xyz/
tags/
RELEASE_1_0_0/
trunk/
README
bin/
lib/
One could have:
README
bin/
branches/
BRANCH_xyz/
lib/
tags/
RELEASE_1_0_0/
I think I might prefer this approach, if possible. The problem of
course is in creating new tags and branches, i.e. making a copy, I
would need to prevent the tags/ and branches/ directories from being
copied in the process. Is there a way to do that?
Thanks,
trans
Re: Keeping tags/ and branches/ in the "trunk"
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, trans!
> Is it possible to keep tags/ and branches/ in the trunk/ so as not to
> have to differentiate these three at the top of a repository.
Everything is possible, but ask yourself, do you really want to checkout whole
repository every time you request to checkout trunk?
> In other words, instead of:
> branches/
> BRANCH_xyz/
> tags/
> RELEASE_1_0_0/
> trunk/
> README
> bin/
> lib/
> One could have:
> README
> bin/
> branches/
> BRANCH_xyz/
> lib/
> tags/
> RELEASE_1_0_0/
> I think I might prefer this approach, if possible. The problem of
> course is in creating new tags and branches, i.e. making a copy, I
> would need to prevent the tags/ and branches/ directories from being
> copied in the process. Is there a way to do that?
And this one, too.
Read svnbook... SVN is a filesystem, all basic rules of file handling apply.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 25.01.2010, <17:45>
Sorry for my terrible english...
Re: Keeping tags/ and branches/ in the "trunk"
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 25, 2010, at 17:38, Daniel Shahaf wrote:
> Ryan Schmidt wrote on Mon, 25 Jan 2010 at 17:10 -0600:
>>
>
>> it also prevents you from using the usual way to create tags, i.e.
>> copying the trunk to the branches or tags directory -- in your scheme,
>> you can't do this, because you can't copy a directory into itself.
>>
>> $ svn cp trunk trunk/branches/foo
>> svn: Cannot copy path 'trunk' into its own child 'trunk/branches/foo'
>
> Works with URLs:
>
> % svn cp ^/trunk/ ^/trunk/foo -mr2
Yes, but the branch now contains a copy of any other branches or tags that had already been created. This layout is just nonsense and should not be considered.
Re: Keeping tags/ and branches/ in the "trunk"
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ryan Schmidt wrote on Mon, 25 Jan 2010 at 17:10 -0600:
>
> On Jan 25, 2010, at 07:25, trans wrote:
>
> > Is it possible to keep tags/ and branches/ in the trunk/ so as not to
> > have to differentiate these three at the top of a repository.
>
> I'm going to go with a firm "no" on this one. Do not attempt to do
> this. Instead, follow the standard layout.
>
> In your scheme, not only, as you've noticed, would checking out the
> trunk also check out all branches and all tags, which would be
> wasteful,
+1. (If you think for a moment, it's going to be O(n^2) in the number of
branches/tags.)
> it also prevents you from using the usual way to create tags, i.e.
> copying the trunk to the branches or tags directory -- in your scheme,
> you can't do this, because you can't copy a directory into itself.
>
> $ svn cp trunk trunk/branches/foo
> svn: Cannot copy path 'trunk' into its own child 'trunk/branches/foo'
>
Works with URLs:
% svn cp ^/trunk/ ^/trunk/foo -mr2
Committed revision 2.
% svn up
A foo
A foo/A
A foo/A/B
A foo/A/B/lambda
A foo/A/B/E
A foo/A/B/E/alpha
A foo/A/B/E/beta
A foo/A/B/F
A foo/A/mu
A foo/A/C
A foo/A/D
A foo/A/D/gamma
A foo/A/D/G
A foo/A/D/G/pi
A foo/A/D/G/rho
A foo/A/D/G/tau
A foo/A/D/H
A foo/A/D/H/chi
A foo/A/D/H/omega
A foo/A/D/H/psi
A foo/iota
Updated to revision 2.
%
>
>
>
Re: Keeping tags/ and branches/ in the "trunk"
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 25, 2010, at 07:25, trans wrote:
> Is it possible to keep tags/ and branches/ in the trunk/ so as not to
> have to differentiate these three at the top of a repository.
>
> In other words, instead of:
>
> branches/
> BRANCH_xyz/
> tags/
> RELEASE_1_0_0/
> trunk/
> README
> bin/
> lib/
>
> One could have:
>
> README
> bin/
> branches/
> BRANCH_xyz/
> lib/
> tags/
> RELEASE_1_0_0/
>
> I think I might prefer this approach, if possible. The problem of
> course is in creating new tags and branches, i.e. making a copy, I
> would need to prevent the tags/ and branches/ directories from being
> copied in the process. Is there a way to do that?
I'm going to go with a firm "no" on this one. Do not attempt to do this. Instead, follow the standard layout.
In your scheme, not only, as you've noticed, would checking out the trunk also check out all branches and all tags, which would be wasteful, it also prevents you from using the usual way to create tags, i.e. copying the trunk to the branches or tags directory -- in your scheme, you can't do this, because you can't copy a directory into itself.
$ svn cp trunk trunk/branches/foo
svn: Cannot copy path 'trunk' into its own child 'trunk/branches/foo'
Re: Keeping tags/ and branches/ in the "trunk"
Posted by "C. Michael Pilato" <cm...@collab.net>.
trans wrote:
> Hi--
>
> Is it possible to keep tags/ and branches/ in the trunk/ so as not to
> have to differentiate these three at the top of a repository.
[...]
> I think I might prefer this approach, if possible. The problem of
> course is in creating new tags and branches, i.e. making a copy, I
> would need to prevent the tags/ and branches/ directories from being
> copied in the process. Is there a way to do that?
I'm ... confused. You're asking us how you can differentiate tags and
branches in a directory scheme that you've designed specifically to avoid
differentiating tags and branches? This is madness.
If you truly wish to avoid differentiation of this sort, just omit the
"branches" and "tags" container directories and make all these items (tags,
branches, and the trunk -- which is just a special sort of branch after all)
siblings:
/
trunk # ah... good ol' trunk.
issue-1414-dev # perhaps a branch -- but is it?
release-1.0 # looks kinda tag-ish -- but is it?
chicken-wire-and-vasoline # *shrug* beats me!
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Keeping tags/ and branches/ in the "trunk"
Posted by Andy Levy <an...@gmail.com>.
On Mon, Jan 25, 2010 at 11:05, trans <tr...@gmail.com> wrote:
>
>
> On Jan 25, 9:30 am, Andy Levy <an...@gmail.com> wrote:
>
>> I don't understand what advantage this would give you. I do see the
>> potential for a lot of confusion and copying/moving of items which
>> shouldn't be operated on, though.
>>
>> Subversion itself applies no special meaning to "tags" & "branches" so
>> there is nothing *technical* from stopping you from doing this; it
>> seems like you're going against convention for no discernible reason
>> though.
>
> Merely convenience --perhaps a minor reason, but a reason nonetheless.
> At least for me, I find it nice to have the source code closer to the
> surface. Having now used git for some projects its one of the things I
> find I like about it. However I prefer Subversion's approach to tags
> and branches. So I simply wondered, would it be possible to have both?
>
> But there are problems with the approach, e.g. checking out the trunk
> would pull down the tags and branches as well. So I am inquiring if
> there is anyway to configure Subversion to exclude paths from a
> checkout, as well as tagging, branching, etc. that would make this
> doable.
Sparse Checkouts will handle the former, but the latter you'll have to
step very carefully or script your branching & tagging (and may have
to do it in steps, instead of all at once).
Re: Keeping tags/ and branches/ in the "trunk"
Posted by trans <tr...@gmail.com>.
On Jan 25, 9:30 am, Andy Levy <an...@gmail.com> wrote:
> I don't understand what advantage this would give you. I do see the
> potential for a lot of confusion and copying/moving of items which
> shouldn't be operated on, though.
>
> Subversion itself applies no special meaning to "tags" & "branches" so
> there is nothing *technical* from stopping you from doing this; it
> seems like you're going against convention for no discernible reason
> though.
Merely convenience --perhaps a minor reason, but a reason nonetheless.
At least for me, I find it nice to have the source code closer to the
surface. Having now used git for some projects its one of the things I
find I like about it. However I prefer Subversion's approach to tags
and branches. So I simply wondered, would it be possible to have both?
But there are problems with the approach, e.g. checking out the trunk
would pull down the tags and branches as well. So I am inquiring if
there is anyway to configure Subversion to exclude paths from a
checkout, as well as tagging, branching, etc. that would make this
doable.
trans
Re: Keeping tags/ and branches/ in the "trunk"
Posted by Andy Levy <an...@gmail.com>.
On Mon, Jan 25, 2010 at 08:25, trans <tr...@gmail.com> wrote:
> Hi--
>
> Is it possible to keep tags/ and branches/ in the trunk/ so as not to
> have to differentiate these three at the top of a repository.
>
> In other words, instead of:
>
> branches/
> BRANCH_xyz/
> tags/
> RELEASE_1_0_0/
> trunk/
> README
> bin/
> lib/
>
> One could have:
>
> README
> bin/
> branches/
> BRANCH_xyz/
> lib/
> tags/
> RELEASE_1_0_0/
>
> I think I might prefer this approach, if possible. The problem of
> course is in creating new tags and branches, i.e. making a copy, I
> would need to prevent the tags/ and branches/ directories from being
> copied in the process. Is there a way to do that?
I don't understand what advantage this would give you. I do see the
potential for a lot of confusion and copying/moving of items which
shouldn't be operated on, though.
Subversion itself applies no special meaning to "tags" & "branches" so
there is nothing *technical* from stopping you from doing this; it
seems like you're going against convention for no discernible reason
though.