Handling of unknown files

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

Post Reply
Alec
Posts: 9
Joined: Wed Mar 17, 2004 9:28 am

Handling of unknown files

Post by Alec » Wed Mar 17, 2004 9:47 am

We're trying the demo version of Vault 2.0.1 and have imported a VSS database with about 19000 files. We currently use SourseOffsite to access the database.

The options for handling Unknown files don't seem very useful to me. If I do a Get Latest, my choices seem to be to overwrite everything, including items I've checked out or to leave everything unknown. I don't know what Automatic Merge does, but I'm sure I don't want it. There doesn't seem to be any special handling, as in SOS, of items that are writable or that I have checked out. Am I missing something?

If this was only going to happen the first time each of our developers used Vault, I might not be too concerned, but our experience with SOS says that Unknown files will pop up from time to time and it concerns me that files are so easily lost. I'm aware of the backup folders, but every file seems to wind up in there so it's not much help in figuring out what you might have lost.

On a possibly related topic, some of our developers do work both in the office and at home. They typically move the files between the two locations while they're working on them. Are they going to be able to check-in something from home that they've checked out in the office? Vault seems to be much more picky about knowing the state of files than SOS and I'm getting the impression that this might be a problem.

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Re: Handling of unknown files

Post by dan » Wed Mar 17, 2004 1:48 pm

Alec wrote: The options for handling Unknown files don't seem very useful to me. If I do a Get Latest, my choices seem to be to overwrite everything, including items I've checked out or to leave everything unknown. I don't know what Automatic Merge does, but I'm sure I don't want it. There doesn't seem to be any special handling, as in SOS, of items that are writable or that I have checked out. Am I missing something?

If this was only going to happen the first time each of our developers used Vault, I might not be too concerned, but our experience with SOS says that Unknown files will pop up from time to time and it concerns me that files are so easily lost. I'm aware of the backup folders, but every file seems to wind up in there so it's not much help in figuring out what you might have lost.
Unknown files are very bad in Vault. Unlike VSS/SOS, Vault needs a baseline on the client to in order determine what has changed, so it can send just the differences to the server. It won't allow you to checkin a file that is unknown. You must overwrite it in order to get the baseline.

If you have an Unknown file that you know has been edited, you have to save it off, then do the Get, then overwrite the file with the saved copy for Vault to know what to do with it.

The only way a file would flip back to Unknown would be if you delete your working folder associations.

In the next major release, we plan to handle Unknown files better - compare the CRCs of the files against versions in Vault in order to determine the baseline.

On a possibly related topic, some of our developers do work both in the office and at home. They typically move the files between the two locations while they're working on them. Are they going to be able to check-in something from home that they've checked out in the office? Vault seems to be much more picky about knowing the state of files than SOS and I'm getting the impression that this might be a problem.
You can checkout a file to two separate machines, and they are treated as separate checkouts. You can turn off Require Checkout before Checkin, and check a file in from a different machine, BUT, again, you need to make sure you have the same baseline of the file on both machines - otherwise copying the file from one place to another will likely lose someone else's changes.

Alec
Posts: 9
Joined: Wed Mar 17, 2004 9:28 am

Post by Alec » Wed Mar 17, 2004 3:58 pm

You can checkout a file to two separate machines, and they are treated as separate checkouts. You can turn off Require Checkout before Checkin, and check a file in from a different machine, BUT, again, you need to make sure you have the same baseline of the file on both machines - otherwise copying the file from one place to another will likely lose someone else's changes.
Since, in general, I would not want our developers to be doing multiple checkouts or checking things in without checking them out, it seems my only real option is to use the Admin tool from home and undo my office checkout, do the checkout from home, and then check it in. This seems like a real loss of functionality from what I had with SOS. Are there any plans to change this?

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Wed Mar 17, 2004 5:26 pm

Alec wrote: Since, in general, I would not want our developers to be doing multiple checkouts or checking things in without checking them out, it seems my only real option is to use the Admin tool from home and undo my office checkout, do the checkout from home, and then check it in. This seems like a real loss of functionality from what I had with SOS. Are there any plans to change this?
I doubt we will change this, since it is pretty integral to Vault's design (requiring a baseline file to determine what has changed).

Another approach would be to checkin the file before leaving work and then check it out from home.

Also, don't be too wary of concurrent development :) These features exist for the problem you have - a file being edited in multiple places at the same time. They work very well and are quite useful once you get comfortable with them.

swildermuth

Anyway to...

Post by swildermuth » Wed Mar 17, 2004 10:28 pm

I wonder if there were anyway to just repopulate the baselines so you can do your diff's. That would seem to be a good middleground between the current behavior (which is very problematic.

Alec
Posts: 9
Joined: Wed Mar 17, 2004 9:28 am

Post by Alec » Thu Mar 18, 2004 10:56 am

Also, don't be too wary of concurrent development
I guess it's a matter of philosophy, but I think the CVS style misses half the point of having source control (OK, maybe a quarter of the point). When we first started using VSS 5 or 6 years ago, we tried allowing multiple checkouts and quickly turned it off because we found it was a recipe for disaster. Maybe your developers are a lot smarter than ours. If you had a Nostalgia forum, I could tell you how we did source control 30 years ago.

Allowing multiple checkouts would be a little less objectionable, but we're using VB6 and many of the files are binary, so I would have to lie about which file types are mergeable. Since my merging would consist of "keep my version and throw away everything else" I suppose it might work. I would also have to threaten to break the fingers of anyone who actually checked out a file that was checked out by someone else. Perhaps you could offer an option to only allow multiple checkouts to the same user.

The other suggestion, to check in everything before leaving, I also don't find very practical for several reasons, but the main one is that I would be checking in code that's probably wrong and might not even compile.

I'm sorry if I keep on harping on this issue. I'm finding a lot of good features in Vault, but it is disappointing that I don't have a good way of doing something that SOS handled pretty easily. I would think that there are a lot of other deverlopers who would like to move work between home and office without opening up a lot of IMHO objectionable holes.

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Thu Mar 18, 2004 4:39 pm

If you are using VB, you definitely don't want to be tweaking which files are mergable so you can check files in from home. Since VB files don't merge very well, you'd probably get into more trouble than it is worth.

However, if you do use a strict non-concurrent development style, then all you would have to do to reset the baselines is to do a Get latest at home, and then copy the changed files over that, since no one else would have modfied the file since the time you first checked it out at work.

You do have the extra step of undoing the checkout via the Admin tool if you want to check it in from home. Yes, this is a loss of functionality from SOS, but it is a by-product of the other concurrent features, which require the baseline files.

Sorry this is disappointing. Hopefully the other added features in Vault will make up for this :)

Post Reply