Conflicting merges must be solved by developers.
All developers are part of the same company on several sites.
A merge leads to a lot of conflicts involving several developers (for ex. During N -> N+1 synchronization while N and N+1 project versions are running in the same repository)
--- Here is my solution:
• All the conflicts are managed in a clone, merging_clone
• This clone is shared at OS level
• Developers of remote sites can connect to a local LAN Git machine to access merging_clone
1. The merge is started
2. Merges are detected and the integration team advises developers in charge of these pieces of code
3. The integration team gives tokens to avoid access conflicts on merging_clone
4. Each developer starts git mergetool, solves his conflicts, and frees his token.
More specificly, integration of GIT and Bugzilla using SCMBug?
I am trying to achive the below tasks
1. SCM to DT - Comments are synced
2. Mail Notification
3. Change Bug Resolution State
4. Verification of Presence Of Distinct Bug Ids
5. Verification of names used in labeling operations, match a configurable label naming convention
6. Verification of valid SCM To Bug-tracking Username Mapping via LDAP
7. Verification of valid Product Name
8. Verification of valid Bug Owner
9. Verification of Open Bug State
We are in the process of evaluating GiT for our developers to use for source control. We already have CA SCM, but they said it does not branch well so they want to use a different tool just for their development state.
One of the requirements is to lock down the GiT repositories so that each team can only update their code. I'm not seeing a way to do this without giving the developers access to the file system where the code is stored.
We have LDAP and would like to use that so that we don't have to manange security seperately. We would give the team read/write/update access to the folder on the file system, but that would not stop them from updating the code outside of GiT.
I'd be interested in feedback from others on this subject, and particularly comparing and contrasting the use of distributed tools such as git and mercurial (and others) vs their more centralised brethren, be they open source (subversion) or commercial.
The requirements for developing something like Linux are certainly different to those for many commercial organisations IMO.