Please settle the check and block vs update and merge the version control discussion
I've been using source controls for several years (if you count years of source safe), but I'm not an expert. We are currently using an older version of SourceGear Vault. Our team is currently using a check and block model. I'd rather switch to the update and merge model, but you need to convince other developers.
The reason the developers (not me) are set to work is because the validation and blocking was caused by the renegade. Our company works with a consulting firm to carry out most of our developments. A few years ago, long before my time here, they had source control set up to update and merge. The consultants went to register, but encountered a merge error. They then decided to work offline for months . When it came time to test the project, bugs were plentiful and it was found that the code bases vary greatly. Weeks of work have been redone. Therefore, they decided to check and block the solution.
I don't like checking and blocking because it makes it difficult for two or more people to work on the same project at the same time. Whenever you add a new file of any type, or change the filename, the source controller checks the .csproj file. This prevents other developers from adding / renaming files.
I was considering creating only the file .csproj
as a merge, but the Sourcegear site says that this is a bad idea because csproj is an auto-generated IDE and that you cannot guarantee that two different files from VS generate the same code.
A friend of mine (another developer) tells me the solution is to validate your project immediately. The problem for me is that I may have a local copy that won't build and it may take a while to build. It could be a few hours before I get the build to work, which means that no one else will be able to create and rename files during this time.
I argue that switching to a pluggable model is the right decision. My answer to the "ugly files" question is that this is a problem of poor programmer discipline and that you should not use weaker programmer choice as a fix for bad discipline; instead, you must take action to correct the lack of programmer discipline.
So who's right? Is registration? Check out the legitimate answer to the problem with the modified file? Or is the problem .csproj
too complex for multiple developers? Or is Sourcegear wrong and that it should be ok to install the csproj
update and merge file ?
source to share
The upgrade and merge issue you encountered was due to a lack of communication between your group and the consulting group and a lack of communication in the consulting group with your group regarding the issue, not necessarily an issue with the revision control method itself. Ideally, the communication problem should be solved first.
I think your technical analysis of the differences between the two version control methodologies sounds good, and I agree that update / merge is better. But I think the real issue is communicating with the people in your group (s) and how this becomes apparent when using version control, and whether people in groups are on board / comfortable with the version control process selected ... Note that as I say my own group at work is struggling with the same, only with Agile / SCRUM instead of VC. It hurts, it is annoying, it is frustrating, but the trick (I think) is to identify the root problem and fix it.
I think the solution here is to make sure that (whichever VC method is chosen) communicates well to everyone, and that the tricky part is you have to get not only your crew on board with a specific VC technique, but also consulting groups. If someone from the consulting team doesn't know how to perform a merge operation, try teaching them. The key is to keep the message open and clear so that problems can be rectified when they arise.
source to share
- Use the correct version control system (svn, mercurial, git, ...)
- If you're going to be doing a lot of forking, don't use anything less recent than svn 1.6. I guess mercurial / git would be an even better solution, but I don't have too much hands-on experience using them.
- If people are constantly working on the same parts of the system, consider the design of the system. This indicates that each unit has too much responsibility.
- Never, ever take people offline for more than a day or so. Exceptions to this rule should be extremely rare.
- Talk to each other. Let other developers know what you are working on.
Personally, I would avoid having project files in my repository. But then again, I would never block developers to one tool. Instead, I would use a build system that generated project files / makefiles / whatever (CMake is my taste for this).
EDIT: I think the lock files capture symptoms, not disease. You end up with developers if it becomes a habit.
source to share
I've worked on successful projects with 40+ developers teams using the update and merge model. What this method does is frequent merges: Independent workers constantly update (flush) changes from the repository, and each one often merges their changes (as soon as they pass the basic tests).
Merging often tends to mean that each merge is small, which helps a lot. Testing often, both on separate codebases and at night checkouts from the repository, helps a lot.
source to share
I am a development manager for a small company, only 3 programmers. The projects we work on sometimes take weeks and we use the style of big bang, shock and awe. This means that we have a lot of database changes and program changes that should work great on the night we implement. We test the program, change it, and postpone it because implementing it before everything else makes 20 other things explode. I am in favor of checking and blocking. Otherwise, another person may change some things without realizing that the program has already had massive changes. And merge only helps if you haven't made changes to the database or changes to other systems not under source control. (Microsoft CRM, basically any packaged software,expandable by configuration)
source to share
We use subversion with no check in / out restrictions for any files in a highly parallel environment. I agree that the issue of renegade files is a matter of discipline. Not using merge does not solve the underlying problem, what prevents a developer from copying their "patched" copy of the code over other people's updates?
Merging is a pile of bread, but this can be minimized by checking and updating the local copy early and often. I agree with you regarding violations of the registration rules, they should be avoided. On the other hand, updating your local copy with checked changes will force you to merge your changes correctly so that everything goes smoothly on final check-in.
As for the .csproj files. They are just text, they really merge if you take the time to structure the file, there are internal links that need to be preserved.
I don't think the files needed to build a project should be excluded from version control. How can you reliably rebuild or track changes if parts of the project are not written down?
source to share