Exclusive lock on build

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
jsiegmund
Posts: 49
Joined: Wed May 09, 2007 3:39 am
Location: Breda
Contact:

Exclusive lock on build

Post by jsiegmund » Mon Jun 11, 2007 8:30 am

I've got a VS2005 solution with multiple projects. One of these projects is a global library containing some default functionalities we're using in several projects. Now, when I build the project itself (which is dependant on the library project) the library project is checked out exclusively. Why is that, and how can I prevent sourcecontrol from doing this? A build action, which (I think) doesn't alter anything in the project (except for the build number maybe?) shouldn't result in a checkout, and definitely not an exclusive one.

I've unchecked all options concerning exclusive checkouts because we don't want our environment to checkout exclusively (we're not experiencing merge conflicts, so there's no need to).

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Mon Jun 11, 2007 10:21 am

Are you using the integration with VSIP or MCSCCI? A bug has been logged with the VSIP IDE. We are working on the fix now, but I'm not sure how long it will take for resolution. It should be fairly soon, but it won't be in 4.0.1 which is coming out this week.

jsiegmund
Posts: 49
Joined: Wed May 09, 2007 3:39 am
Location: Breda
Contact:

Post by jsiegmund » Tue Jun 12, 2007 12:55 am

I'm using the Visual Studio plugin. A solution would be great because the exclusive checkout on the project file really bumps with concurrent development (now I've still got to shout to my colleagues to release the project :))

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Tue Jun 12, 2007 7:23 am

Another thing to remember is that binary files and .proj and .sln files are checked out exclusively as a general rule.

jsiegmund
Posts: 49
Joined: Wed May 09, 2007 3:39 am
Location: Breda
Contact:

Post by jsiegmund » Tue Jun 12, 2007 7:34 am

That's fine, but I presume VS is only meant to check out the project file if something is really altered in there, not on every build.

ian_sg
Posts: 787
Joined: Wed May 04, 2005 10:55 am
Location: SourceGear
Contact:

Post by ian_sg » Tue Jun 12, 2007 9:53 am

When this happens, is a change being made to the project file? Vault should have a pending change for the checked-out project file, and it would be "Modified" if the file's contents have changed. Visual Studio often makes spurious changes to project files and I'm wondering if this is the case here. (Note this is not an attempt to blame Visual Studio. I still consider it likely we'll tweak something to prevent this behavior. I'm just trying to understand the scenario.)

What would also help track this down is if you could turn on logging, reproduce the problem, and send me the log. (At that link, follow the directions for Visual Studio 2005. For classes to log, "vsip ide" will be sufficient.)
Ian Olsen
SourceGear

jsiegmund
Posts: 49
Joined: Wed May 09, 2007 3:39 am
Location: Breda
Contact:

Post by jsiegmund » Wed Jun 13, 2007 1:40 pm

I don't know... I'm out of the office visiting the local devdays and some other MS tracks, so I won't be able to test it untill two weeks. I'll give myself a reminder and will follow up on this.

ian_sg
Posts: 787
Joined: Wed May 04, 2005 10:55 am
Location: SourceGear
Contact:

Post by ian_sg » Wed Jun 13, 2007 1:47 pm

Thanks. If we reproduce this or have other updated info, I'll let you know here.
Ian Olsen
SourceGear

jsiegmund
Posts: 49
Joined: Wed May 09, 2007 3:39 am
Location: Breda
Contact:

Post by jsiegmund » Fri Jun 29, 2007 8:57 am

We've been looking into this and found the following problem:

When a change is made to the project, for instance when a file is added, the solution file is automatically checked out exclusively. The Visual Studio IDE doens't always alert the user about this (sometimes it does). The exclusive checkout causes problems for other users which are suddenly unable to add another file to the project since that requires an alteration to the project file. This behaviour is definitely unwanted and I would like to file in a bugreport for this since it really messes with concurrent development.

ian_sg
Posts: 787
Joined: Wed May 04, 2005 10:55 am
Location: SourceGear
Contact:

Post by ian_sg » Fri Jun 29, 2007 9:13 am

Thanks for the additional information. What type of project are you modifying when you see this?

One other relevant piece of information here regarding checkouts: even if you have "Always request exclusive locks" turned off (under Concurrent Development Style in the options), file types that are not listed as mergeable will be checked out exclusively. By default, solution and project files are not in the mergeable list.
Ian Olsen
SourceGear

jsiegmund
Posts: 49
Joined: Wed May 09, 2007 3:39 am
Location: Breda
Contact:

Post by jsiegmund » Fri Jun 29, 2007 9:17 am

It's a regular C# project. I noticed .proj are always checked out exclusively and that's kind of understandable. But it shouldn't do that on adding a file or an action like that; unless it does an automated checkin after that (but that would be tricky too I guess).

ian_sg
Posts: 787
Joined: Wed May 04, 2005 10:55 am
Location: SourceGear
Contact:

Post by ian_sg » Fri Jun 29, 2007 9:24 am

Okay. Above you said the solution file was being checked out exclusively when you added a file to a project, which concerned me. But now it sounds like you meant that the project file was checked out exclusively, which is to be expected.

When you add a new file to a project, the project file's contents change to include the new file. If your settings indicate that we must checkout the file (Require Check Out before Check In), we automatically check out the project file. Because the project file is not mergeable, it becomes an exclusive checkout. So I'm not considering the behavior a bug at this point.

In a future release, we will support an option (like the 2003-compatible client has) to always alert you when you're about to check a file out, so at least you'll have the opportunity to change your mind.

If development concurrency is a high priority and you're willing to merge file contents when necessary, the CVS-style settings (the big button under "Concurrent Development Style") may suit your needs better. This is the way most of us at SourceGear work.
Ian Olsen
SourceGear

Locked