Nathan Nobbe wrote:
>
>
> What happens when people working in isolation with DVCS make large
> conflicting changes before the code ends up in the same place?
>
>
> well, the flow is actually cleaner than what youll find in a centralized
> model; b/c while theyve been offline, everything has been versioned.
> so, when they signal upstream saying changes are ready and upstream
> finds that the work conflicts badly w/ mainline; what happens ?
> downstream is given the url to the latest upstream and tasked w/
> integrating the changes on their side. and this is ideal since the
> conflicts are coming in part b/c of these folks whove created them.
I don't understand. Conflicts are caused by two or more people making
different changes. How does a decentralized model get these different
people who may not even be on the network together to agree on a common
set of changes?
> so
> then once theyve resolved the conflicts, they again publish the
> downstream work in a public location.
Which user makes the change? How does he know it resolves conflicts
with changes others are making?
> upstream can then pull w/o conflict.
> note similar flows can be attained in centralized systems via branching
> / meriging, however the tendency is for centralized users to avoid this
> because of the overhead in doing so.
There are times you want to make conflicting changes - making branching
and working in isolation appropriate or necessary.
> ive actually used a very similar flow w/ svn in our 30 dev env.
> basically what i do is branch off mainline and check it out in a common
> location. then run the merge there (which will be the same as merging
> directly to upstream). then i send a message to the developers, to log
> in and resolve the conflicts theyre reponsible for. once all the
> conflicts are resolved; i can then merge that dedicated branch to
> upstream w/o conflict (assuming the issues have been resolved w/o too
> many commits on upstream in the meantime, otherwise some other iteration
> of the process has to occur).
Unless you have a specific plan to break things, why not take advantage
of other team members changes as early as possible instead of isolating
them?
> there are many benefits to this flow, however its time consuming in svn
> so i tend to save it for the truly painful merges.. anyway, like i
> said, the tendency in my exp, is for centralized vcs users to sit around
> not committing (eg sharing upstream) let alone branching and merging on
> their own; lol!
That might happen with a team of volunteers, but it doesn't make sense
where someone is actively managing the project.
> whether or not its a tendency of dvcs users to sit
> around not pushing to upstream remains to be seen.
> ideally resolving merge conflicts is best handled by the folks
> responsible, not some third-party maintainer. i find this goal easier
> to attain in dvcs than cvcs.
I'm missing something then. Other than the ability to work offline and
not share all of your work, what functionality does dvcs provide that
you can't get by isolating your changes in a branch if you are so
inclined or the nature of your change requires it?
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2360948
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-10 16:59:59 CEST