> -----Oorspronkelijk bericht-----
> Van: Nathan Nobbe [mailto:quickshiftin_at_gmail.com]
> Verzonden: woensdag 10 juni 2009 18:38
> Aan: David Weintraub
> CC: users_at_subversion.tigris.org
> Onderwerp: Re: Distributed Subversion
>
> On Wed, Jun 10, 2009 at 8:37 AM, David Weintraub <qazwart_at_gmail.com>
> wrote:
>
[...snip...]
>
> It took me a couple of weeks to realize what as happening. Since
> the developers all work on the same branch, they had to constantly
> think about how their work affected the other developers. They talked
> to each other about the changes they were making. They made their
> changes in small increments. They worked together and made sure
> everyone knew what was going on.
> This was a great relevation to me. By isolating the developers'
> work on separate branches, we isolated the developers from each other.
> They could work without worrying what their changes might do to their
> fellow developers. They no longer needed to talk to each other.
> In fact, the developers hated delivery code changes because
> that's when everyone gets mad. In order to avoid code deliveries, the
> developers broke off big chucks of changes. That way, when someone
> asked about their changes, they were still busy with them. Of course,
> the delay in deliverying their changes only made the inevidable merge
> worse.
> DVCS worry me because I can see the same effect going on:
> Developers working on their own without worrying how their changes
> might affect other developers.
> In a commercial environmment where you have third party imposed
> deadlines, you want to force your developers to work together. You want
> them to deliver small incremental improvements as quickly as possible.
> Yes, you could enforce this with a DVCS by simply having everyone work
> on the same repository. But then, it's not really a DVCS.
>
>
> great read david, thanks for sharing.
>
>
> As long as you don't do updates or commits, you can easily work
> with Subversion off line.
>
>
> the only thing about this is, offline work w/ svn means work w/o
> committing; which encourages the most horrid of practices. basically
> contrived techniques that vary from dev to dev but mostly amount to
> managing copies of directories w/ diff names on them... which basically
> gets you to the point of - why are you bothering to use a vcs in the
> first place..
>
> good to hear more practical examples. admittedly, ive not had the
> opportunity to use dvcs much so far, as adoption is only now starting
> to ramp up. im sure there will be pain points in the distributed flows
> that i just have yet to discover.. and start complaining about - lol.
>
>
> -nathan
Interesting discussion, all of this. I tend to agree with David here. We used to be on CVS, recently migrated to SVN, and that's really what I feel is happening at our place: developers are used to exposing their changes in small increments all the time, and seeing others' changes quickly. Any conflicts that need to be resolved are always small (there are exceptions of course, but generally our devs don't work in isolation for long).
For our situation (commercial env, local team with devs talking to each other frequently, ...), I can currently only see two possible advantages of DVCS over SVN:
1) Ability to keep dev-local branches, work off-line, commit locally, ...: in our case, I don't see this as a big issue, because this kind of feature is already provided by our IDE (IntelliJ IDEA). We have:
- local history (can be kept for x days)
- Shelving and creating patches right from the IDE. I can just right click a series of changes (or a change-set) in the "Changes tool window", and select "Shelve changes" or "Create patch". If I'm half-way through a new feature, and need to put the work aside to perform a small bug-fix in the same source file, I can do it this way.
I don't see what a DVCS offers me on top of this, except giving me this outside of my IDE.
2) Performance
In our environment we experience three major performance problems with SVN: update, log and blame. None of these are network-related (these things went relatively fast from CVS, with the same amount of data going over the wire):
- update: this is, I think, mainly WC-related (we are on Windows, so I guess for example http://subversion.tigris.org/issues/show_bug.cgi?id=3369 plays a big role). I hope this will be vastly improved with the WC-NG for 1.7 (?)
- log: this is pure server side. Should be improved someday IMHO, with some buffering/caching/lookup structure....
- blame/annotate: also pure server side issue. Same as for log: should definitely be improved someday.
All in all, I believe these performance issues should be resolved in SVN. I'd not like to switch to another (D)VCS just for performance's sake ... I like the current tooling support, and believe that a centralized model is the right model for us right now. I just hope someday SVN devs will be able to tackle those performance issues...
Just my 2 cents.
Regards,
Johan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2362143
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-15 13:59:07 CEST