On Aug 23, 2:09 am, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
On Mon, 22 Aug 2011 05:14:29 -0700 (PDT)
Sandeep Mahajan sandeep.d.maha...@gmail.com wrote:
[...]
1. Assume I have a central repo containing branches branchA.
2. This repo is cloned by user A and userB.
3. userA creates a new branchB where he merges in branchA.
4. There is a conflict reported, and only userB has the skills to
resolve the conflict.
Question: How can userB view the same conflicts, and get them
resolved in branchA?
UserA pushes its BranchB to the server, UserB fetches it and then
attempts to merge whatever UserA tried to merge into BranchB.
After that, BranchB can be deleted from the server.
Lets extrapolate on this and make it a bit more complicated.
1. I have a central repo containing branch1 and branch2
2. branch1 and 2 have 3 files - file1, file2 and file3
3. This repo is cloned by userA, userB, userC- each user owning file1,
file2 and file3 respectively
4. Assume the three files have conflicting changes in branch1 and
branch2 in central repo
5. Now an integration build engineer BuildUser clones the central
repo.
6. He creates a new branch branchBuild where he merges the branch1 -
no conflicts.
7. Then he merges in branch2 - gets conflicts in file1, file2 and
file3. This branch is pushed across to remote central repo.
8. Now these conflicts need to be resolved by userA, userB and userC.
9. Should users - userA, userB and userC, all clone from the repo,
check out branchBuild and merge in the same branch1 followed by
branch2 to see the same conflicts?
Is there any alternative to step9?
It seems a bit of overkill to get three users (userA, userB and userC)
to replicate the same set of steps taken by an integration build
engineer only to solve conflicts.
Is there any other alternative way without requiring these users to
merge the branches just to see the conflicts?
Well, I'm not sure about how exactly to approach this question...
One thing to start with, which is worth keeping in mind, is that a
merge conflict is by definition a case which has to be resolved by a
human. That's why merging is always performed in the work tree.
Now you have an integration engineer which does not possess the
necessary knowledge to resolve a merge conflict and a natural
requirement for the merge to happen in someone's work tree. This
suggests that to make the owning user to resolve the conflict is the
only sensible solution in your case with anything else being wishful
thinking. And this act requires the user to do merging against her
work tree which requires her to fetch the necessary head(s) first.
Hence I cannot imagine how the situation like yours could be solved
without your users performing their respective merges themselves.
If this still appears to be clumsy, you could probably look at this
problem from an opposite point of view: let each of your users perform
the first part of the job envisioned for the integration engineer. I
mean, each user first creates her own integration branch into which
she merges her changes (or rebases them) and then pushes that branch to
the central repo. Provided each user only touched her owned file on
her respective branch, she would only get merge conflicts for that
file and she knows how to resolve those conflicts. Then the task
for the integration engineer whould be to merge the resulting three
branches coming from the users. If the patchsets in the users' branches
were really isolated from each other such merging should occur without
conflicts.
Also you seem to consistently use the clone word while one of the
key ideas behind a DVCS is its ability to do minimal data transfers.
The users from your scenario do not need to (re-)clone the repo,
instead, they just have to *fetch* one intergation branch (pushed by
the integration engineer) and this act is not really a big deal in terms
of network traffic and disk space. So if you're mostly concerned with
these traffic/space issues you should rather not be.
P.S.
Please don't top-post, this breaks discussion flow and hence sucks.
Thanks again.
I take your point that I'll have to get my users to perform part of
the integration engineer work i.e. do part of the merges themselves.
I'll try out the scenario.
My mistake I referred to 'clone'ing repeatedly. A fetch would suffice.
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
