On Wed, Jun 10, 2009 at 8:58 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> 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?
there are actually a variety of possibilities. imagine 3 people, devA
maintainerA, and devB. maintainerA pulls some code from devA's public repo,
and merges into the common upstream branch; which maintainerA then publishes
to the public repo for this common upstream branch. maintainerA then pulls
and attempts to merge devB's latest work; when maintainerA then discovers
non-trivial merge conflicts, there are several choices
. resolve the conflicts anyway - high risk of error
. tell devB about the newly updated public version of the upstream branch,
which now include devA's changes. devB will then pull from the public repo
and resolve the conflicts. then maintainerA can cleanly pull from devA's
public repo.
. tell devA to pull from devB's public repo and resolve the conflicts
(perhaps devA is more experienced w/ the code or w/ vcs or w/e..). devA
then again updates the corresponding (devA's) public repo, and now
maintainerA can pull cleanly
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?
is it possible to develop w/o breaking things? every time a developer makes
a change and commits, you are at risk of breaking things. part of the
problem w/ centralized flows is people sit on their code until its 'perfect'
for fear of screwing everyone else. this makes devs reluctant to commit and
lends them instead to the tendencies i mentioned earlier, which are
contrived version management practices.
using dvcs, i can get you my code just as quickly as i do w/ svn. as soon
as its ready, i push it to my public repo. the next time you want stuff
from me, you just pull again. if something more is there, you get it, if
youre up to date, theres nothing.
> 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?
just imagine you started off your svn repo layout by creating a branch for
every user. from there, they would be responsible for creating sub-branches
or 'twigs' as i sometimes call them, and also responsible for managing
merges from their high-level 'developer-level' branches to the twigs theyll
be creating.
now when you the maintainer come through and want to start integrating code,
into a release branch (from which the developer branches were branched) you
can do it piecemeal, one feature at a time. if at some point you encounter
a problem (merge conflicts non-trivial) you branch off the developers
branch, creating what i call a 'merge branch' (a branch specifically for a
particular merge). you then tell the developer to checkout this branch and
run the merge from the current release branch to this new merge branch,
resolve the conflicts and commit. then you the maintainer can cleanly merge
that branch back into the release branch.
this is much cleaner than trying to do the same w/o the developer branches
where all the features commits are intertwined.
also, this sort of flow is cumbersome to create and manage in centralized
systems (though it sounds like clear case may simplify things based on
davids' last post). this flow is totally natural in dvcs, and btw, merge
semantics in dvcs systems are way better, so merging is fast and effective.
i read on this list a month or so back svn is handinling like 50-60 files
per second on a merge and its supposedly fast.., yet git can do *thousands*
of files per second. plus i have to stop and think about whether its time
to branch to avoid a goofy limitation in the merge tracking, or find out it
wasnt smart enough to omit previously merged changesets.., and start writing
another bash script w/ several merge commands, carefully skipping over the
already merged revisions...
-nathan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2360989
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-10 18:36:31 CEST