I thought I understood the basics of adding files/folders, check out and check in. However, I'm a bit confused about how these things work in practice. Here is a description of what I'm doing...
1. Add a file to vault
No problem.
2. Check out the file added in 1.
No problem
3. Check in the checked out file.
Problem. I get a window pops up in Vault with three rows for the same file. There is no information in the display that helps me differentiate between the three files except in the 'type' column that indicates 'Add', 'Add' and 'Unmodified'.
By default, all three files are selected/checked and, if I just accept these defaults and try to check in, it fails with a transaction error. It also fails with one of the two 'Added' files. It only succeeds with the check in by selecting the 'Umodified' file. A question on this... If there is only one real choice, why am I presented with other options that will fail?
Another question, I am using Final Builder Pro to create a build process and using it's 'Vault Actions' to check out and in. Repeating the same test as above but using Vault Actions in Final Builder, checking out is not a problem. However, when I try to check in, it fails with a message that there is already a file in the folder with that name or object id. I wonder if this is because the Vault Check In action doesn't differentiate between the three files when, apparently, only one of them is valide (ie. the unmodified file)?
To explain more about what I am trying to achieve, my Final Builder build process generates a script (a delta file to upgrade a database) that I want to add to source control. The file's name stay's the same. I assumed that I could check out the file before the new script is generated and then check in the new script. The aim is to keep a history of these delta files/scripts in source control. What the build file does is just to overwrite the checked out file - no modify it. If I'm doing something wrong, how do this?
Clive
trying to understand check out/in
Moderator: SourceGear
I think I can explain some of your check-in confusion.
What you're seeing is a result of a very nice feature for source control, namely changesets.
The idea is that you can group all the changes made to many files for a particular update together and check them in all at once.
For example suppose that in order to fix a particular bug you deleted one source file, created a new source file, modified the project to remove the 1st file and add the 2nd, and modified a 3rd file.
After you've compliled and tested this change in your working folder you want to check it in. If you check in just the modified project file when someone else gets it and tries to build they will fail because they don't have the new file you created. What you really want to do is check in everything at once.
FileX ---> delete
FileN ---> add
ProjFile ----> update
File3 ----> update
In Vault you can have all 4 of those actions in your "Pending Changeset"
If for some reason any of the actions cannot be completed when you try to commit the changeset, none of the action will be done, leaving your repository in a consistent state.
So what happened in your case is that your Pending Changeset contains the 3 lines you were describing:
File1 ---> add
File1 ---> add
File1 ---> update (unmodified)
Somehow you have added the add action of your file to your pending changeset twice, AFTER having done it and committed it once before.
Vault won't allow you to add a file that already exists, and therefore the commit of the transaction fails. When you uncheck the add actions from the changeset so that it only contains the update, then the commit can succeed.
One other thing to note: it is possible (as you've seen) to get multiple actions on the same file into your changeset which is almost always (maybe ALWAYS) not a good idea, and that will usually cause the commit to fail. In your example with 2 adds of the same file, the 2nd add would fail even if the 1st one succeeded because the file would exist at that point.
I hope this helps,
Mike
What you're seeing is a result of a very nice feature for source control, namely changesets.
The idea is that you can group all the changes made to many files for a particular update together and check them in all at once.
For example suppose that in order to fix a particular bug you deleted one source file, created a new source file, modified the project to remove the 1st file and add the 2nd, and modified a 3rd file.
After you've compliled and tested this change in your working folder you want to check it in. If you check in just the modified project file when someone else gets it and tries to build they will fail because they don't have the new file you created. What you really want to do is check in everything at once.
FileX ---> delete
FileN ---> add
ProjFile ----> update
File3 ----> update
In Vault you can have all 4 of those actions in your "Pending Changeset"
If for some reason any of the actions cannot be completed when you try to commit the changeset, none of the action will be done, leaving your repository in a consistent state.
So what happened in your case is that your Pending Changeset contains the 3 lines you were describing:
File1 ---> add
File1 ---> add
File1 ---> update (unmodified)
Somehow you have added the add action of your file to your pending changeset twice, AFTER having done it and committed it once before.
Vault won't allow you to add a file that already exists, and therefore the commit of the transaction fails. When you uncheck the add actions from the changeset so that it only contains the update, then the commit can succeed.
One other thing to note: it is possible (as you've seen) to get multiple actions on the same file into your changeset which is almost always (maybe ALWAYS) not a good idea, and that will usually cause the commit to fail. In your example with 2 adds of the same file, the 2nd add would fail even if the 1st one succeeded because the file would exist at that point.
I hope this helps,
Mike