3

I've used source controls for a few years (if you count the Source Safe years), but am by no means an expert. We currently are using an older version of Sourcegear Vault. Our team currently uses a check out and lock model. I would rather switch to a update and merge model, but need to convince the other developers.

The reason the developers (not me) set up to work as check out and lock was due to renegade files. Our company works with a consulting firm to do much of our development work. Some years ago, long before my time here, they had the source control set up for update and merge. The consultants went to check in, but encountered a merge error. They then chose to work in a disconnected mode for months. When it was finally time to test the project, bugs galore appeared and it was discovered that the code bases were dramatically different. Weeks of work ended up having to be redone. So they went to check out and lock as the solution.

I don't like check out and lock, because it makes it very difficult for 2 or more people to work in the same project at the same time. Whenever you add a new file of any type or change a file's name, source control checks out the .csproj file. That prevents any other developers from adding/renaming files.

I considered making just the .csproj file as mergable, but the Sourcegear site says that this is a bad idea, because csproj is IDE auto-generated and that you cannot guarantee that two different VS generated files will produce the same code.

My friend (the other developer) tells me that the solution is to immediately check in your project. To me, the problem with this is that I may have a local copy that won't build and it could take time to get a build. It could be hours before I get the build working, which means that during that time, no one else would be able to create and rename files.

I counter that the correct solution is to switch to a mergable model. My answer to the "renegade files" issue is that it was an issue of poor programmer discipline and that you shouldn't use a weaker programmer choice as a fix for poor discipline; instead you should take action to fix the lack of programmer discipline.

So who's right? Is check in - check out a legitimate answer to the renegade file issue? Or does the .csproj issue far too big of a hassle for multiple developers? Or is Sourcegear wrong and that it should be ok to set the csproj file to update and merge?

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
John
  • 3,332
  • 5
  • 33
  • 55
  • 1
    I think the usual terms for these two models are "check out and lock" vs "update and merge". – DigitalRoss Sep 16 '09 at 16:42
  • Why are people voting to close this? – Paul Nathan Sep 16 '09 at 16:50
  • 1
    I don't quite understand - why would making the .csproj file mergeable fix your problem? Is it not the actual code files that you would want to be mergeable? – Michael Wiles Sep 16 '09 at 16:53
  • The problem right now is not so much the ability to merge individual files, because our work is segregated so that we're creating and editing different files than one another. That could become a bigger issue in the future, but for right now, it's not. Our bigger issue is that once I create a new class, js file, css file, etc., it prevents anyone else from creating their own new files until I check in the project, because of the locked csproj file. – John Sep 16 '09 at 17:28
  • So making csproj mergeable seemed like a step in the right direction, if not entirely ideal. But then I cam across the Sourcegear recommendation that you shouldn't use unpredictable auto-generated code as mergeable files (though I don't necessarily subscribe to their conclusion that csproj files are undpredictable). – John Sep 16 '09 at 17:34

6 Answers6

5

The problem with update and merge that you guys ran into was rooted in a lack of communication between your group and the consulting group, and a lack of communication from the consulting group to your group as to what the problem was, and not necessarily a problem with the version control method itself. Ideally, the communication problem would need to be resolved first.

I think your technical analysis of the differences between the two version control methodologies is sound, and I agree that update/merge is better. But I think the real problem is in the communication to the people in your group(s), and how that becomes apparent in the use of version control, and whether the people in the groups are onboard/comfortable with the version control process you've selected. Note that as I say this, my own group at work is struggling through the exact same thing, only with Agile/SCRUM instead of VC. It's painful, it's annoying, it's frustrating, but the trick (I think) is in identifying the root problem and fixing it.

I think the solution here is in making sure that (whatever VC method is chosen) is communicated well to everyone, and that's the complicated part - you have to get not just your team on board with a particular VC technique, but also the consulting team. If someone on the consulting team isn't sure of how to perform a merge operation, well, try to train them. The key is to keep the communication open and clear so that problems can be resolved when they appear.

J. Polfer
  • 12,251
  • 10
  • 54
  • 83
2
  1. Use a proper source control system (svn, mercurial, git, ...)
  2. If you are going to do a lot of branching, don't use anything less recent than svn 1.6. I'm guessing mercurial/git would be an even better solution, but I don't have too much hands-on-experience using those yet.
  3. If people constantly are working on the same parts of the system, consider the system design. It indicates that each unit has too much responsibility.
  4. Never, ever accept people to offline for more than a day or so. Exceptions to this rule should be extremely rare.
  5. Talk to each other. Let the other developers know what your are working on.

Personally I would avoid having project files in my repository. But then again, I would never ever lock developers to one tool. Instead I would use a build system that generated project files/makefiles/whatever (CMake is my flavor for doing this).

EDIT: I think locking files is fixing the symptoms, not the disease. You will end up having developers doing nothing if this becomes a habit.

larsmoa
  • 12,604
  • 8
  • 62
  • 85
  • He's talking about developing with Visual Studio. Project files are part and parcel of the IDE. – Nick Sep 16 '09 at 17:02
  • I'm using Visual Studio and we don't have any project files in the repository. In fact, the only place project files are stored is locally. They are generated from CMake. – larsmoa Sep 16 '09 at 17:03
2

I have worked on successful projects with teams of 40+ developers using the update-and-merge model. The thing that makes this method work is frequent merges: the independent workers are continuously updating (merging down) changes from the repository, and everyone is frequently merging up their changes (as soon as they pass basic tests).

Merging frequently tends to mean that each merge is small, which helps a lot. Testing frequently, both on individual codebases and nightly checkouts from the repository, helps hugely.

system PAUSE
  • 37,082
  • 20
  • 62
  • 59
0

We are using subversion with no check-in/check-out restrictions on any files in a highly parallel environment. I agree that the renegade files issue is a matter of discipline. Not using merge doesn't solve the underlying problem, what's preventing the developer from copying their own "fixed" copy of code over other people's updates?

Merge is a pita, but that can be minimized by checking in and updating your local copy early and often. I agree with you regarding breaking checkins, they are to be avoided. Updating your local copy with checked in changes on the other hand will force you to merge your changes in properly so that when you finally check-in things go smoothly.

With regards to .csproj files. They are just text, they are indeed mergeable if you spend the time to figure out how the file is structured, there are internal references that need to be maintained.

I don't believe any files that are required to build a project should be excluded from version control. How can you reliably rebuild or trace changes if portions of the project aren't recorded?

segy
  • 644
  • 4
  • 12
0

I am the development manager of a small company, only 3 programmers. The projects we work on sometimes take weeks and we employ the big bang, shock and awe implementation style. This means that we have lots of database changes and program changes that have to work perfectly on the night that we implement. We checkout a program, change it and set it aside because implementing it before everything else will make 20 other things blow up. I am for check out and lock. Otherwise, another person might change a few things not realizing that program has had massive changes already. And the merge only helps if you haven't made database changes or changes to other systems not under source control. (Microsoft CRM, basically any packaged software that is extensible through configuration)

Tom Graham
  • 1
  • 1
  • Downvoting because your underlying issue here, I think, is your fragile deployment practice (and presumably lack of testing, judging from your other comments), so you can’t be confident about the quality of your codebase. If you have a properly tested and properly stable codebase, then any developer can make changes and be confident that they will work, so the need for locking goes away and developers can work more efficiently as a result. – Marnen Laibow-Koser Sep 13 '18 at 15:28
-1

IMO, project files such as .csproj should not be part of the versioning system, since they aren't source really.

They also almost certainly are not mergeable.

Paul Nathan
  • 39,638
  • 28
  • 112
  • 212
  • 1
    just because they aren't source doesn't mean they cannot be in the repo. Lots of files are not strictly source and they're in the repo. – Michael Wiles Sep 16 '09 at 16:54
  • 1
    Project files are xml that maintain a list of references and project contents, they are text and should be in version control. If I add a class to a project and don't have my csproj in version control, when someone else tries to edit the solution or project my class won't show up for them. – Nick Sep 16 '09 at 17:00
  • If the .csproj file is a file needed to build, it should be checked in. – system PAUSE Sep 16 '09 at 17:01
  • Everything that *is needed* to build should be in the repo. You should be able to make a check out/update and builb from source. – Esteban Küber Sep 16 '09 at 17:03
  • The problem is, the project files are getting clobbered. So they aren't strictly source; they need to be treated differently. – Paul Nathan Sep 16 '09 at 17:04
  • Clobbered how? Clobbered in the sense that changes from multiple users are merged together in a single file? – Nick Sep 16 '09 at 17:09
  • I don't understand. Step 1 in Vault or VSS for downloading an existing project is to specify the .csproj or .sln file from the source control database. How would a developer ever set up a project without a current proj file? – John Sep 16 '09 at 17:19
  • csc and ms make? (my preferred solution) – Paul Nathan Sep 16 '09 at 17:39
  • I understand the do-it-yourself attitude, I was a linux guy for a long time. But when doing Windows development, why go to extra lengths to do more work when Visual Studio is actually a pretty good IDE. – Nick Sep 16 '09 at 17:49
  • Well, the project IDE files having clobbering problems from user conflicts seems to be a good case for an independent build file. And, yes, there are cases where you can't escape the IDE, I know. – Paul Nathan Sep 16 '09 at 17:56