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.
In that case, perhaps /branches/ebcdic/* and /tags/ebcdic/* make the most
sense?
> 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.
(BTW: We don't enforce partial committer domains via technological means -
it's a scheme which works out pretty well, since then when a partial
committer comes up with a patch for an area of the tree outside their
authorization, a full committer can check it over and give approval by
email. Personally, I think it's also part of a secret conspiracy to tempt
people into becoming sufficiently involved with Subversion to become full
committers :-) )
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 12 15:34:48 2005