TFS - Exclusive Checkout / SVN - Lock
It would be really nice if there was a way to checkout or lock db objects so that I know that I'm the only person working on this object and I will not experience any conflicts when I go to commit the object.
AdminRed Gate Administrator
(Admin, Red Gate)
shared this idea
31 comments
-
Stephen
commented
I like @Andrew Hartley's suggestion of a manual flag. Having developers working in two locations a thousand miles apart means you can't exactly call over the cube for a quick "anyone changing XXX?" Manual "mark this as being worked on", with a userid of course, would be very helpful shy of exclusive checkouts everywhere.
-
Andrew Hartley
commented
Happy to compromise on a manual flag option as I'm sure an auto exclusive checkout will require a completely different mechanism to identify changes. We need to be able to flag an object as being edited so that other devs can see and at least have a conversation about whether to merge changes or wait for one change to be checked in before starting the next. We would use this for about 5% of our changes, but they are the time consuming complex headache-generating changes that we don't want to be made even more complicated by sifting through a merge process - please...
-
sam
commented
yes I would like exclusive checkout to prevent others from overwriting my code in shared environment.
-
J. Verdurmen
commented
We also would like this feature.
-
Seth
commented
In response to David's question, I think it is important to support both the ability to lock an object as well as allow multiple people to work on the same object. In the second scenario, I think it is important to alert them that something they are working in is checked out by another developer; in a fashion for than just an indicator on the object. They should have to perform a check out and get notified that "<user> also has <object> checked out."
-
vt
commented
Locking feature would be very much useful
-
Anonymous
commented
Yes, we want a locking feature.
-
AdminDavid Atkinson
(Admin, Red Gate)
commented
Can I ask why this feature is important for you? The modern trend for source control is not to use exclusive locking.
-
HY
commented
We are delaying the purchase of this product to my whole team because of this missing feature.
-
Brad
commented
This will be a great feature and a deal clincher with management to purchase this product. Trying to resolve conflicts and merge changes of parallel development has wasted too much time in the past and it would be far nicer, safer and simpler if changes were done exclusively. If that's not possible, then even a notification that someone else has made changes that haven't been committed yet would be a good start.
-
David Feiler
commented
I agree; we need this lock functionality, or we won't really be able to use the integration. We rely on this to avoid conflicts
-
zacuke
commented
We are considering using SVN-Lock to prevent multiple people from editing one object in a shared database environment.
-
Alex
commented
I also vote fore Check-In/Check-Out option.
-
AdminDavid Atkinson
(Admin, Red Gate)
commented
@Seth - which is more important, preventing another user from modifying an object you're working on, or letting them know that you're working on it, so they work on it at their own risk?
-
Seth
commented
I too vote for this. Being able to lock an object you are working on so that other developers know that you are working on it is a must. We still use the product and like it a lot, but this would be a great feature to have.
-
AdminDavid Atkinson
(Admin, Red Gate)
commented
@Craig - are you all sharing a database, or do all developers have their own? What problems would you anticipate without this feature?
-
Craig
commented
I too would like to vote for this feature.. It seems fundamental to us for a multi-developer environment.
This is an issue that is stopping us from implementing redgates SQL Source Control into our development processes. -
Will
commented
I am going to vote for this. I'm having a hard time convincing my developers to use SQL Source Control due to this feature (and tagging as well, but that's another story). It's been my experience that most developers working on SQL Server "grew up" with Source Safe, in which exclusive checkout/SVN lock is the default behavior. I've worked extended periods of time in a non-Microsoft shop, so copy-modify-merge doesn't bother me. However, I am the exception.
-
Ben
commented
Well it would obviously prevent concurrency issues where if two of our developers were working on say the same stored procedure - the 2nd person in to execute their alter script would over-write the other person's changes, possibly without them even knowing. The same problem occurs when it comes time to check-in (or 'committ' as used in your software) the changes into your source control system.
I guess one big thing to note is that i'm coming from an application development environment where we have a SQL DB backend, as opposed to just being dedicated DB developers. The standard model for app source control, as you're no doubt aware, is check-out the file (for simplicity we only allow single concurrent check outs) and obtain a lock on the file, perform your changes and check it back in. We're using TFS to do this. So it would be best if we can apply the same processes to managing the source for DB development.
Now while your product appears unique (at least as opposed to using say a VS2010 DB project) in that it will detect changes in the DB automatically, (which is really, really nice) it just doesn't quite fit our preferred development process. But if you add DB object locking we'd have to versy seriously consider using your product. But at the moment, it looks like we'll probably start using VS2010 DB projects and perform all of our DB development from VS, rather than SMSS.
-
AdminDavid Atkinson
(Admin, Red Gate)
commented
@Ben - could you let us know what is the primary reason that exclusive locking is important for you? In other words, what existing problem would the introduction of this feature solve for you?
