Re: Git vs SVN (was: Can we improve things?)

On Mon, 2007-09-10 at 16:41 -0700, Sanford Armstrong wrote:
> On 9/8/07, Jeff Waugh <jdub perkypants org> wrote:
> > <quote who="Sanford Armstrong">
> >
> > > I simply meant that less people are familiar with D-SCM tools and that
> > > they are somewhat harder for a newbie to learn than C-SCM tools.
> >
> > This is an unfortunate cultural relic created by arch/tla, and hilariously
> > promulgated by git. Sure, fewer people are familiar with them, but the good
> > ones are not harder to learn.
> I'm not really talking about the UI of the D-SCM tool, but about some
> fundamentals of the distributed model.  Getting code and pushing code
> seems to always require an additonal step.  Users have to learn about
> branching and merging up front, whereas in SVN this would come later
> in their education.  If I were a newbie developer I would find this
> confusing.  As I've stated, I don't have much experience with D-SCM,
> but these are the instructions to get started hacking on one project
> using bzr...
> $ bzr init-repo --trees some-project
> $ cd some-project
> $ bzr checkout http://url/to/some-project
> $ bzr branch mainline working
> $ cd working
> $ ./configure
> $ make

Maybe there is. I'm not certain I would want to check something out.
That is the same workflow problem this thread is discussing.

Just skip the checkout, branch, make lots of changes and commits
(uncommits, shelves, unshelves, and merges) until you are sure you have
something that someone else is interested in. after pushing the changes
to a public place. Ask the third party for review, and that party could
do the merge and commit. If your very privileged, you can do the merge
into mainline and commit yourself.

> ...compared to the same steps using svn...
> $ svn co http://url/to/some-project/trunk some-project
> $ cd some-project
> $ ./configure
> $ make
> There's just a higher cognitive investment for a newbie getting
> started with D-SCM.  As bzr/git/etc become more common in the FLOSS
> communities, this won't be as much of an issue, though.  And the
> advantages of the distributed model have been well covered here.  :-)

The initial investment for both is still conceptional, and it takes the
same amount of time. The only people who have a higher investment are
people learning multiple workflows. Everyone working with versioning
systems needs to understand repositories, where the code is, how to get
it, how to record/report their changes, and how to publish.

D-SCM benefits people who are not the maintainers, or are offline
frequently. The project maintainers remain in authority to oversee
oversee and accept changes. The advantage is that developers who are not
in authority can exchange and collaborate on a project without special
(and possibly dangerous) power. When their work is good enough for
mainline, it can be accepted by the maintainers. D-SCM provides a
workflow for non-privileged users to achieve more in the time they have
to contribute.


__C U R T I S  C.  H O V E Y_______
Guilty of stealing everything I am.

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]