Garance A Drosihn <drosih@rpi.edu> writes:
> I cannot see Linus giving 400+ people access to his personal
> repository, and I cannot see FreeBSD switching to have a "pull"
> model for bringing updates into the "official" project repository.
I don't see a real distinction between "push" and "pull" here. We
could just as easily say 400 people have the ability to "pull" changes
from their personal repositories into the main FreeBSD repository. It
doesn't matter whether it's 1 or 400 developers doing it, or how many
repositories each developer has write access to.
>>When I talked to Brian Fitzpatrick about this, he listed three
>>things as top priorities:
>>
>> - Faster. Subversion does need to be faster for many ops.
>> - Offline commits.
>> - Local branches.
>>
>>I would add "better merging", but basically agree with Fitz
>>(note that we're getting much-improved merging in Subversion 1.5).
>
> What I think I would like is more than just local branches. I
> want branches which are recognized as being totally separate
> from the original repository. Disjoint, separately administered.
> People who have zero write access to a master repository should
> still be able to do track their changes, and track those changes
> wrt the official repository.
Right, that's what I'm talking about.
> Also, from what I can tell, what we're getting is much-improved
> tracking of merges made within a single repository. That is a
> major benefit, of course, but we're still in the mindset of a
> working from a single master repository.
Well, if you're talking about 1.5's upcoming merge-tracking, that's
because it has to work with a single master repository :-).
> I think a full-blown distributed change system is harder for
> the average person to understand, but I think subversion could
> provide a subset of it that would be really easy to explain.
Yeah, that's sort of what I think our course should be.
> To quote from that blog:
>
> So while most people say: "isn't it great that I can fork
> the whole project without anyone knowing!" My reaction is,
> "yikes, why aren't you working with everyone else? why
> aren't you asking for commit access?" This is a problem
> that is solved socially: projects should actively encourage
> side-work of small teams and grant access to private
> branches early and often
>
> This overlooks one key point. Even though CVS and subversion
> do not support any kind of distributed model, developers *WILL*
> do it. They *ALREADY* do it. I have commit access to the
> FreeBSD project, for instance, but there are small works-in-
> progress that I simply do not want to clutter up the main
> repository with. No matter how frilly and wonderful you make
> "collaboration" sound, the fact is that it is counter-productive
> to put things in the official repository until you have some
> idea how it's going to work out. I'm not going to commit
> something and have that CVSUP-ed to 100,000 machines across
> the planet, if I think I might rip out all those changes
> tomorrow just to do it in a completely different manner.
>
> Is it frightening? Well, that's too bad. It is what is in
> fact happening, and it's absurd to pretend that it does not.
> Or to pretend it go away if your SCM doesn't support it.
I agree with you, always have; I expect Ben does too.
> It happens that many developers in the FreeBSD project get
> around this by having a *second* repository, which is sync'ed
> from the official CVS repository and is in perforce. But I
> don't feel like learning perforce just for this benefit. (The
> developers who use it, use it due other benefits. But for
> *me* this would be the only benefit from using the p4-based
> repository).
>
> And I *have* access to the FreeBSD repository. What about
> someone who doesn't have any access, but wants to work on
> some changes before sending in a PR? How are they supposed
> to come up with a patch that they are confident in? Should
> they send in one PR one day, and then send in another PR the
> next day saying "Well, my previous patch was all screwed up,
> but how about this one?". This is not a good way to build
> credibility.
I think you don't realize how much we're already on your page... :-)
> I also have to hand-wave on the details of what I want, because
> I'm still not completely sure what would work right...
>
> I think what I want is to be able to create my own repository,
> and maybe say that the HEAD branch in this new repository is a
> read-only copy of HEAD in the master repository. The local
> HEAD branch would automatically sync-up with the original.
> This obviously presents some technical issues wrt revision
> numbers, etc. Perhaps that could be tracked via a second
> revprop for the mirrored version of the HEAD branch.
>
> And really I'd like to specify more than one branch.
> Something like "Create me a new repository which is a fork
> of <OtherRespository>, starting at July 1/2006, and limit
> that mirroring to just the HEAD and 6.x branches".
Yes. What you want is more or less what I was saying. (SVK is
probably the place we should look for guidance first.)
I think you might have heard me to be saying what you expected me to
say, rather than what I intended to say. (IOW, if you reread my mail
starting from the assumption that I have the same goals you do, I
think nothing will stand out to contradict that assumption.)
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 3 04:05:47 2007