Mark Phippard wrote:
>>Since you won't develop any new features on those branches, I propose a
>>somewhat different naming scheme; either:
>>
>> /branches/ebcdic-trunk
>> /branches/ebcdic-1.1.x
>>
>>or
>>
>> /ebcdic/trunk
>> /ebcdic/1.1.x
>>
>>i.e., put the ebcdic port on the top level alongside /trunk, /tags and
>>/branches. If anyone thinks this is too radical, remember that the
>>repository structure is here to serve us, not the other way around.
>>
>>
>
>Either of those structures would be fine with me.
>
>My main issue is that even the best-case scenario it will probably be quite
>a while before all of this code lands on the main trunk and I want to be
>able to produce releases (mirroring your releases) for OS/400 users in the
>interim. So I need a structure that has branches for those releases. Both
>your suggestions would do that fine, as with mine. I guess my thought was
>that confining all of the activity under a single location, whether it be
>at the repository root, or under a branches folder, would be easier from an
>administrative standpoint. That way I can be authorized to a location, and
>if I need to make a branch, I can just do so.
>
>
Oh, that's not a problem either way. Our commit area restrictions are
not enforced by any kind of ACL settings. So if you're blessed with the
right to commit to the ebcdic port, you can naturally create any
branches you need.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 12 17:15:03 2005