[dSCM] Use case: new committer

[Santiago Gala <sa...@gmail.com>]

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.

Regards
Santiago
-- 
Santiago Gala
http://memojo.com/~sgala/blog/

Re: [dSCM] Use case: new committer

[Santiago Gala <sa...@gmail.com>]

El jue, 01-05-2008 a las 19:35 +0200, Henning Schmiedehausen escribió:
> You are probably talking about r652498.
> 
> That is not a dSCM, cSCM or anything else problem. This is purely a

No "problem". I talked about "use case". As Sander said, it is useful to
be able to split and keep separate commits. You can use emacs+patch
+diff, quilt, ... a lot of tools to do that. Last generation dscm tools
just happen to be some of the best ones for the task.

> "developers too lazy too split" problem. If the shindig project is fine
> with this commit, then who cares. I would probably let the developer
> revert and re-apply in smaller chunks. But this is open source. :-)
> 

No problem here, actually:
a) shindig is incubating, and the PHP input can be considered like
"initial commits" for the moment
b) The current PHP port was brought in, basically, by Chris alone,
except for the initial version by brianm, and a small refactoring
by /me, and some minor patches by other people

As we are getting ready for graduation, those concerns will grow. Now we
are, so to say, testing the waters.

Regards
Santiago

> 	Best regards
> 		Henning
> 
> 
> On Thu, 2008-05-01 at 18:09 +0200, Santiago Gala 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.
> > 
> > Regards
> > Santiago
-- 
Santiago Gala
http://memojo.com/~sgala/blog/

Re: [dSCM] Use case: new committer

[Henning Schmiedehausen <hp...@intermeta.de>]

You are probably talking about r652498.

That is not a dSCM, cSCM or anything else problem. This is purely a
"developers too lazy too split" problem. If the shindig project is fine
with this commit, then who cares. I would probably let the developer
revert and re-apply in smaller chunks. But this is open source. :-)

	Best regards
		Henning


On Thu, 2008-05-01 at 18:09 +0200, Santiago Gala 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.
> 
> Regards
> Santiago
-- 
Henning P. Schmiedehausen  -- hps@intermeta.de | JEE, Linux, Unix
91054 Buckenhof, Germany   -- +49 9131 506540  | Apache Java Software
Open Source Consulting, Development, Design    | 

INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen

  char name_buf[257];           /* max unix filename is 256, right? */

Re: [dSCM] Use case: new committer

[Santiago Gala <sa...@gmail.com>]

El jue, 01-05-2008 a las 19:30 +0200, Sander Striker escribió:
> On Thu, May 1, 2008 at 6:09 PM, Santiago Gala <sa...@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.

Yes, tools are useful, this is all I meant here. I answer this point to
Henning's email.

> 
> 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.

Just realize that there is no line, and draw over yourself :)

I mean, whatever floats each one's boats, as you said.

Regards

> 
> Cheers,
> 
> Sander
-- 
Santiago Gala
http://memojo.com/~sgala/blog/

Re: [dSCM] Use case: new committer

[Sander Striker <s....@striker.nl>]

On Thu, May 1, 2008 at 6:09 PM, Santiago Gala <sa...@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.

Cheers,

Sander

Re: [dSCM] Use case: new committer

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Thu, May 1, 2008 at 10:47 AM, Noel J. Bergman <no...@devtech.com> wrote:
> This is not a dSCM issue.  Subversion will support multiple pending commits
>  in the next release, or so Justin informs us.

Well...kinda sorta.  It's the changelist feature in 1.5.  -- justin

RE: [dSCM] Use case: new committer

[Santiago Gala <sa...@gmail.com>]

El jue, 01-05-2008 a las 13:47 -0400, Noel J. Bergman escribió:
> This is not a dSCM issue.  Subversion will support multiple pending commits
> in the next release, or so Justin informs us.

Cool, that means that it will stop being a dSCM issue when the next
release is released and reasonably deployed. Until then, I consider that
any tool that helps keeping local commits and manage them can help with
this use case.


Regards
Santiago

> 
> 	--- Noel
> 
> 
-- 
Santiago Gala
http://memojo.com/~sgala/blog/

RE: [dSCM] Use case: new committer

["Noel J. Bergman" <no...@devtech.com>]

This is not a dSCM issue.  Subversion will support multiple pending commits
in the next release, or so Justin informs us.

	--- Noel