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. <http://bazaar-vcs.org/CheckoutTutorial> 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