Dustin Sallings wrote:
Um, because svn is not conducive to community development. In order
to branch, I must first have commit access. In order to obtain commit
access, I must first demonstrate that I'm worthy to be in the small
official circle of developers.
During the initial "proving" stage, I have to build a manual workflow
around maintaining my own changes and rebasing them over or merging them
with the upstream changes. This already requires tools beyond what
subversion offers.
In the longer term, we're either cluttering up the official repo with
tons of experimental branches, or we're just not experimenting.
OK, I guess I never understood 'community development' to mean 'making a
lot of clutter that shouldn't be saved', but your description does make
sense.
Either
way, we're only doing so with the elite core or the really determined
(and only when connectivity and availability allow, which it often
doesn't).
I haven't used it, but I thought svk was designed to interact with
subversion in exactly this way - that is you can check out an svn
project as a mirror, then make a local branch for your work. Svk is
supposed to offer the same functionality as svn whether standalone or
with a mirrored svn checkout, but in the latter case when you merge your
branch changes back to the mirrored, checked out copy, it also commits
them back into the subversion repository.
http://www.bieberlabs.com/wordpress/svk-tutorials/
I'm not sure how this works if you initially have read-only rights and
later are granted commit access, but I'd expect it to work.
--
Les Mikesell
[EMAIL PROTECTED]
