Last night I did the following steps.
1. I have CVS-style turned on.
2. I changed a file in visual studio. Visual studio still had the "locked" icon next to my file.
3. I said, "whoops- forgot to checkout". I did a "check out now".
4. Vault tossed reverted the file to the checked in version with NO WARNING. It just clobbered everything.
OK - thats bug #1. No source archival program should ever clobber changes without the user really jumping through hoops. Thats really bad. I think you should patch this immediately.
So, I started looking through the options, and discovered that I had "back up overwritten files" checked. I thought "Phew- I'm ok!". I found the file in the _sgbak directory. But, instead of being the version of the file with my local edits, its a copy of the file that was already checked in!!! Ack!
Thats bug #2.
Mike
Backup files bug
Moderator: SourceGear
Mike,
There are probably multiple backups of the file in the _sgbak directory? None of these are the version that you clobbered? We're hoping to get better backup file management in one of the next releases of Vault.
Your checkout problem comes from the fact that the IDE component is not compatible with CVS-style development. In the IDE component, the hoop that you have to jump through is that it should be very hard to edit the file without checking it out first. This sounds like a Vault bug in that we should force the IDE component to mark all files read-only, regardless of the option (which is the key that makes the IDE prompt you to check the file out when you start editing it). I'll have to investigate more to find out if I can reproduce the sequence you're describing, which is
1. Get the files and have them marked writable.
2. Edit a file in the IDE. There will be no prompt for checkout.
3. Check the file out in the IDE (which should clobber the file, because that is the default setting)
4. Look at the _sgbak directory to see if the clobbered file is there.
There are probably multiple backups of the file in the _sgbak directory? None of these are the version that you clobbered? We're hoping to get better backup file management in one of the next releases of Vault.
Your checkout problem comes from the fact that the IDE component is not compatible with CVS-style development. In the IDE component, the hoop that you have to jump through is that it should be very hard to edit the file without checking it out first. This sounds like a Vault bug in that we should force the IDE component to mark all files read-only, regardless of the option (which is the key that makes the IDE prompt you to check the file out when you start editing it). I'll have to investigate more to find out if I can reproduce the sequence you're describing, which is
1. Get the files and have them marked writable.
2. Edit a file in the IDE. There will be no prompt for checkout.
3. Check the file out in the IDE (which should clobber the file, because that is the default setting)
4. Look at the _sgbak directory to see if the clobbered file is there.
Yeah, those steps should reproduce. There was only one file in the backup area - it had the date appended to it. It was the original version of the file - not the one with my changes.
Maybe it doesn't save-before-overwriting, although I thought I saved it before I did getlatestversion.
Is there any way that you can prevent users from getting into this case? It seems like there are a lot of bugs in the IDE world that lead to loss of work. As an end user, i just shouldn't be able to do that without doing something really whacky. Seems worthy of immediate fix.
Even though I'm aware that this sequence will reproduce loss-of-work, I keep doing it. Its so easy to accidentally do.
Maybe it doesn't save-before-overwriting, although I thought I saved it before I did getlatestversion.
Is there any way that you can prevent users from getting into this case? It seems like there are a lot of bugs in the IDE world that lead to loss of work. As an end user, i just shouldn't be able to do that without doing something really whacky. Seems worthy of immediate fix.
Even though I'm aware that this sequence will reproduce loss-of-work, I keep doing it. Its so easy to accidentally do.
My immediate recommendation for you is to do one of three things.
1. Stop trying to use CVS mode in the IDE. It won't work. because VS.Net does not understand the ability to check in a change for a file that you didn't check out.
2. Stop using the IDE if you want to use CVS mode.
3. Make sure that the Modified local file option is set to Attempt Automatic Merge not overwrite. Overwriting on get/checkout is exactly the oposite of everything that CVS mode stands for.
1. Stop trying to use CVS mode in the IDE. It won't work. because VS.Net does not understand the ability to check in a change for a file that you didn't check out.
2. Stop using the IDE if you want to use CVS mode.
3. Make sure that the Modified local file option is set to Attempt Automatic Merge not overwrite. Overwriting on get/checkout is exactly the oposite of everything that CVS mode stands for.
Thanks for clarifying, Jeremy. I've already started doing that.
The trouble is that I spend so much time in the IDE all day long, and its really easy to think, "hmm. maybe it can handle this case"?
Maybe you should remove CVS mode if it does not work? Or disable the UI or something. From reading the discussions here, it sounds like others do the same thing I did.
The problem is that the non-cvs mode is lame for concurrent development. Its like a retro back to source control of 1970. Who does locked checkouts? OK - well maybe some people do, I don't know. But I've never seen it at any of the companies I've been at over the last 10 years.
You need to either make the feature work or remove it. Don't lead me down paths that lead to data loss.
The trouble is that I spend so much time in the IDE all day long, and its really easy to think, "hmm. maybe it can handle this case"?
Maybe you should remove CVS mode if it does not work? Or disable the UI or something. From reading the discussions here, it sounds like others do the same thing I did.
The problem is that the non-cvs mode is lame for concurrent development. Its like a retro back to source control of 1970. Who does locked checkouts? OK - well maybe some people do, I don't know. But I've never seen it at any of the companies I've been at over the last 10 years.
You need to either make the feature work or remove it. Don't lead me down paths that lead to data loss.
Mike,
Is it possible that you had not saved your file in the IDE before doing the checkout? If so, that would explain the file not getting backed up properly, since the version in the working folder would have still been the repository version, and not your freshly edited version.
We've had people be surprised about files getting overwritten before, but we've never had a reproducible report of a file not being backed up properly on the client before being overwritten. So if you can reproduce this reliably, we would fix it. Preventing data loss is exactly why we back up files and set up default options to not overwrite files.
Note that the most critical concurrent development option does work in the IDE - the ability to allow multiple people to checkout a file at the same time. However, Visual Studio itself doesn't handle the rest of it very well - it requires a file to be checked out before it is checked in, and it also gets very confused about the read-write flags on a file in relation to whether it is checked out or not.
I understand your enthusiasm with concurrent development, but you'd be surprised at just how insistent a lot of other folks are about non-concurrent development, and not wanting to trust merging. So, that's why the options are there - to allow everyone to set it up how they want it.
Is it possible that you had not saved your file in the IDE before doing the checkout? If so, that would explain the file not getting backed up properly, since the version in the working folder would have still been the repository version, and not your freshly edited version.
We've had people be surprised about files getting overwritten before, but we've never had a reproducible report of a file not being backed up properly on the client before being overwritten. So if you can reproduce this reliably, we would fix it. Preventing data loss is exactly why we back up files and set up default options to not overwrite files.
We actually do prevent users from turning on CVS mode from within the options in the IDE client. However, we can't disable it from the GUI client without essentially axing the feature, since we can never know whether a user is going to be later using the IDE client.Maybe you should remove CVS mode if it does not work? Or disable the UI or something. From reading the discussions here, it sounds like others do the same thing I did.
Note that the most critical concurrent development option does work in the IDE - the ability to allow multiple people to checkout a file at the same time. However, Visual Studio itself doesn't handle the rest of it very well - it requires a file to be checked out before it is checked in, and it also gets very confused about the read-write flags on a file in relation to whether it is checked out or not.
I understand your enthusiasm with concurrent development, but you'd be surprised at just how insistent a lot of other folks are about non-concurrent development, and not wanting to trust merging. So, that's why the options are there - to allow everyone to set it up how they want it.