Get latest

[aspindel]

I was promised that a big version control problem in version 2 would be fixed in version 3.

When you check out a file it needs to get latest from source control first so that you don't overwrite the changes someone else may have made.

Please tell me that this has been fixed. I haven't seen this in the change log.

[Michael Bulgrien]

I would think that it would be the user's responsibility to "Get Latest" before "Checking Out".

In some version control software, a "Get Latest" only replaces the local file if it is read-only. If the local file is writeable, it leaves the local file as-is and simply instructs the server-side component to flag the current "latest" as the common ancestor. Since "Get Latest" functionality can vary between version control solutions, how do you propose this "fix" be implemented in BC3? Should BC3 run a background compare first, then provide a checkbox giving the user the option to refresh the local file if it does not match the latest version in version control? I'm sure that some users would consider it a bug if BC3 automatically threw away their local changes without warning.

[Tim]

I was promised that a big version control problem in version 2 would be fixed in version 3.

I believe our promise was to add it to our wishlist for a future release. ;)

It's still on the wishlist and there's a good chance it will make it into the final 3.0 release. (It would have to be an option because as Michael mentioned not everyone would want this behavior.)

[aspindel]

It is not advisable to make your local version writable while it is under source control and not checked out. It defeats the purpose of source control. What BC3 should do in this case is entirely your call, probably ask the user. I would advise making a .BAK file before overwriting a writable file just in case.

****HOWEVER****

The normal case is a read only file under source control because that is the way source control works.

If you are being prompted to check out a read only file then you have not made any changes yet. A refresh from source control would be fine. When I am in visual studio and check out a read only file from there it automatically gets latest before checkout. This allows multiple developers to work on the same code.

If your product did not have source control support at all we would be forced to check out files from our source control program and would (theoretically) never have problems with overwriting other people's work. The current implementation of source control support in BC encourages overwriting other people's work by making it easier to do than to prevent. No source control support at all would be better.

[Craig]

Sorry, the normal case is a only a read-only file for a subset of version control systems, notably Visual Source Safe. Quite a few leave the source controlled files write-enabled and merge any external changes automatically when you update to the newest version. Subversion certainly works that way, and judging from Michael's comments it sounds like Team Foundation Server does too.

[Michael Bulgrien]

Michael's comments it sounds like Team Foundation Server does too.

That is correct. Microsoft has changed what they consider "normal" version control functionality in Team Foundation Server. Visual Source Safe is being phased out.