www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <s.stri...@striker.nl>
Subject Re: [dSCM] Use case: new committer
Date Thu, 01 May 2008 17:30:14 GMT
On Thu, May 1, 2008 at 6:09 PM, Santiago Gala <santiago.gala@gmail.com> wrote:
> I just wanted to launch a use case for a distributed SCM integration,
>  including a concrete example. Just today, a new committer in shindig,
>  committed a big chunk of code. This was because there were problems with
>  his password and all together, he had almost one month delay from being
>  accepted as a committer and being able to effectively commit.
>  Instead of: one big commit of
>  120 files changed, 7404 insertions(+), 3790 deletions
>  he could have committed the 20 tematic commiits that probably this work
>  consisted of. Ha would have kept them (merging or even attaching to
>  issue tracker items) all the work in nice logically related units until
>  he had the ability to push this work forward to the common repository.

There is nothing preventing you from not accepting a powerplant and
insisting on smaller changes.  Yes, it's more effort to commit several
patches and to keep them apart, but this is what I've had to do in the
past as well to keep stuff I wanted to get in sane and reviewable.  Could
a dSCM have been helpful in that.  Maybe.  Could I do it without?
Clearly so.

Also, there is nothing preventing you from using svk or git-svn or
whatever other tool that respects the main svn repository as primary.
I really don't see why we need to invest in trying out another decoupled
repository using some other version control system, for which we need
to maintain separate authorization...  To me, the use case above is
certainly not one to draw me over the line.  But YMMV.



View raw message