Commit order

[avonwyss]

In the feature description of Vault, it states that all operations are atomic so that the repository is not left in a half-baked state. That's nice.

Now the problem I'm facing every now and then is that commiting all pending changes will just not work, especially when items are moved, renamed, and added so that naming conflicts occur if those operations are not done in the correct order.

However, being able to perfom the whole batch as one atomic operation is important when using automated processes (such as continuous integration etc.), since the project is otherwise left in this "half-baked" state between the commit operations.

For instance, if I have a file A in the repository which I first rename to B, and then add another file named A, the commit will usually not be able to be performed in one batch:

Code: Select all

Preparing data to begin transaction
Beginning transaction
Item $/A caused the transaction to fail: An item with the same name or object id already exists in the selected folder.
Transaction failed

Why doesn't the client keep a sequence number or the the UTC date when the operation was initiated (checked out time for edits), so that the commit can perform the single operations of the batch in the correct order?

[ian_sg]

This is strange, because the client does almost exactly what you describe (sort change set items before sending them to the server), for the reasons you give.

What client are you using to perform this commit? What version? Is there a simple case the reproduces this problem?

[avonwyss]

This is strange, because the client does almost exactly what you describe (sort change set items before sending them to the server), for the reasons you give.

Is it sorted by change type or is it sorted by a sequence/date?

What client are you using to perform this commit? What version?

This specific issue happened with the VSIP client 4.1.2.18185, but I has similar issues before with the normal GUI client (maybe with an older client version, but it was some V4.x for sure).

Is there a simple case the reproduces this problem?

For the issue per se (autocommit disabled, normal client):
- rename a file (whether it is checked out or not doesn't matter)
- add a file with the old name of the renamed file
- try to commit (see screenshot)
-> commit fails: "Item $/test2.txt caused the transaction to fail: An item with the same name or object id already exists in the selected folder."

While trying to reproduce the issue, I got another funny one:
- check out and edit a file
- delete this file (no autocommit!)
-> the file is removed from the pending change set, the deletion is visible
- remove the deletion from the pending changeset
-> the client now displays the file as (checked out) renegade, change set is empty!

[ian_sg]

Thanks for the detailed report. I'll look into this.

[GregM]

Ian, I've wanted this for a long time. I don't think I've ever seen this work. If it did, that would be great.

[ian_sg]

I've reproduced this and logged a bug.

We made some intentional strides in this area in 4.0, but obviously it's not yet 100%. This bugs me personally, so I'm motivated to get it on a schedule, but it's not yet on one.

Thanks for the feedback.

[avonwyss]

I've reproduced this and logged a bug.

Great, looking forward to the fixed version!

We made some intentional strides in this area in 4.0, but obviously it's not yet 100%. This bugs me personally, so I'm motivated to get it on a schedule, but it's not yet on one.

Sorry to bug you more, I've just got another one (normal Vault client):
- Moved a file from a subfolder into another folder in the repository
- Deleted the folder containing the subfolder where the file previously was
-> Commit failed: Item $/Change Scripts/1/Data.sql caused the transaction to fail: The source object path is not found in the tree.
(which is true only if the deletion of "change scripts" occured before the move)

[ian_sg]

Thanks.