(v3.1.8 client and server)
1) If I try and rename a file and modify the file in the same changeset Vault seems to get very confused when I do the commit:
"<my file name> caused the transaction to fail: A modification to this item was requested earlier in the same transaction"
Often a file modify and rename need to be committed as one operation -- it appears Vault can't do that?
2) Another related issue: When I rename (or move) a file, it doesn't get renamed locally until the changeset is committed and you do a 'get'. But until it's renamed locally I can't test my build, so I end up having to check in untested code, then doing a 'get'. This is a major problem when renaming many files.
jim
can't rename and modify in same changeset
Moderator: SourceGear
In the current version, a rename and a modification to a file cannot be done in the same change set.
We do have feature requests logged to:
--support certain cases of multiple changes to one item in a changeset
--rename the file in the working folder if the file has been renamed in the repository.
I'll add your "vote" and bump them up in priority.
We do have feature requests logged to:
--support certain cases of multiple changes to one item in a changeset
--rename the file in the working folder if the file has been renamed in the repository.
I'll add your "vote" and bump them up in priority.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Yes, I've run into this bug as well. I figured it was part of the bug that I'd already reported about how it is very difficult to do any large operation, because if you mistakenly add any piece again, or remove any file again, as you keep adding or removing files building your changeset, it will cause your latest operation to fail, and you can lose a large selected list.
But now that you describe it clearly, I realize it is a somewhat different issue.
This bug is exacerbated by the lack of visual feedback in the selection tree area (the top part of Vault GUI), so you don't have any feedback to catch when you're conflicting with the existing changeset, until you finish creating your new set of additions (ie, finish your new multiselect, or typing in your new name), *and* until you try commit the entire changeset. This is an annoying part to me -- that it happily builds up illegal changesets, letting me invest more work, when the whole changeset is doomed to failure already.
I'd concluded that it often isn't worth my time trying to fight the IDE to create consistent logical changesets -- it is better to compromise, and give up on complete logical changesets, in the interest of fitting within the tools currently convenient capabilies. That is, it is better to settle for committing serially several (or many) changesets that really ought to all be together -- and hope that noone pulls a copy in the time period in betweeen any of the serial pieces.
But now that you describe it clearly, I realize it is a somewhat different issue.
This bug is exacerbated by the lack of visual feedback in the selection tree area (the top part of Vault GUI), so you don't have any feedback to catch when you're conflicting with the existing changeset, until you finish creating your new set of additions (ie, finish your new multiselect, or typing in your new name), *and* until you try commit the entire changeset. This is an annoying part to me -- that it happily builds up illegal changesets, letting me invest more work, when the whole changeset is doomed to failure already.
I'd concluded that it often isn't worth my time trying to fight the IDE to create consistent logical changesets -- it is better to compromise, and give up on complete logical changesets, in the interest of fitting within the tools currently convenient capabilies. That is, it is better to settle for committing serially several (or many) changesets that really ought to all be together -- and hope that noone pulls a copy in the time period in betweeen any of the serial pieces.