Plz fix bug: Unable to pin a shared file if it's ch....
Moderator: SourceGear
-
- Posts: 52
- Joined: Wed Jul 12, 2006 5:38 am
Plz fix bug: Unable to pin a shared file if it's ch....
Plz fix bug: Unable to pin a shared file if it's checked out in another branch.
This bug (reported) is terribly annoying, and dangerous in our workflow.
Symptoms:
Item $/prod_plan/s/lib/somefile.i caused the transaction to fail: The object could not be modified because it or one of its children is checked out.
Transaction failed
The above message is displayed when the file is checked out in i.e. $/dev/s/lib/somefile.i .
It was pinned, unpinning was allowed (while it was checked out from $/dev, so that is okay). But you can't undo it (re-pin) it, it fails with the message above. So then I have to call the programmer who has the file checked out (in evening hours this time), to temporarily undo the checkout (with 'keep local version'), let me do my work, after I did a simple pin action in prod_plan (meaning here: planned to go into production), he can checkout the file in dev again, but must not forget to set the option to "Leave/Merge later" or his changes might be lost forever.
I do the unpin and the pin from a History window b.t.w.. It doesn't matter how I try it though, direct pinning (on the latest version), or via the vault command client, or via the api, the bug is always there. Seems to be a server side bug.
I beg you, please fix this soon.
I must say I'm kind of disappointed of the amount of time SourceGear programmers need to fix simple bugs. You have basically a good product, and since you yourself probably use it, you must be able to make changes quickly. A weekly 'minor upgrade' of vault with patches, is that too much to ask?
B.t.w. the support in the forum here is absolute top rate, I definitely must mention that. For bugfixing - the saying 'put your money where your mouth is' comes to mind...
Best regards, in hope of a better Vault, M. (Tijs) Wickardt, Bertus Distributie.
This bug (reported) is terribly annoying, and dangerous in our workflow.
Symptoms:
Item $/prod_plan/s/lib/somefile.i caused the transaction to fail: The object could not be modified because it or one of its children is checked out.
Transaction failed
The above message is displayed when the file is checked out in i.e. $/dev/s/lib/somefile.i .
It was pinned, unpinning was allowed (while it was checked out from $/dev, so that is okay). But you can't undo it (re-pin) it, it fails with the message above. So then I have to call the programmer who has the file checked out (in evening hours this time), to temporarily undo the checkout (with 'keep local version'), let me do my work, after I did a simple pin action in prod_plan (meaning here: planned to go into production), he can checkout the file in dev again, but must not forget to set the option to "Leave/Merge later" or his changes might be lost forever.
I do the unpin and the pin from a History window b.t.w.. It doesn't matter how I try it though, direct pinning (on the latest version), or via the vault command client, or via the api, the bug is always there. Seems to be a server side bug.
I beg you, please fix this soon.
I must say I'm kind of disappointed of the amount of time SourceGear programmers need to fix simple bugs. You have basically a good product, and since you yourself probably use it, you must be able to make changes quickly. A weekly 'minor upgrade' of vault with patches, is that too much to ask?
B.t.w. the support in the forum here is absolute top rate, I definitely must mention that. For bugfixing - the saying 'put your money where your mouth is' comes to mind...
Best regards, in hope of a better Vault, M. (Tijs) Wickardt, Bertus Distributie.
-
- Posts: 52
- Joined: Wed Jul 12, 2006 5:38 am
Good to hear you fixed this (and thanks for the very swift reply).
Still, since you already fixed it - why not release a beta? Or a minor version?
A couple of months is a lot of time, and my team has been waiting for this bugfix for a couple of months already. Since you've already fixed it.... why not make them happy?
Best Regards, M. Wickardt
Still, since you already fixed it - why not release a beta? Or a minor version?
A couple of months is a lot of time, and my team has been waiting for this bugfix for a couple of months already. Since you've already fixed it.... why not make them happy?
Best Regards, M. Wickardt
-
- Posts: 52
- Joined: Wed Jul 12, 2006 5:38 am
Hi Linda, thanks for your answer.
I still press the development / testing team to tweak their release schedule in the future. Bugfixes should, in my opinion, always have priority over new features. You should try to get them released sooner, and implement them in the current version as well as in the future version with more features.
I understand that this would change your workflow, and probably can't be implemented half-way to the 3.5.2 release in an orderly fashion. So that means we have to wait for another few months for now. I hope you will change this in the future.
Regards, M. Wickardt
I still press the development / testing team to tweak their release schedule in the future. Bugfixes should, in my opinion, always have priority over new features. You should try to get them released sooner, and implement them in the current version as well as in the future version with more features.
I understand that this would change your workflow, and probably can't be implemented half-way to the 3.5.2 release in an orderly fashion. So that means we have to wait for another few months for now. I hope you will change this in the future.
Regards, M. Wickardt
Vault 3.5.2 is a maintenance release, and does not have new features. We have a number of bug fixes and performance enhancements in this release.
Here's a partial list:
http://support.sourcegear.com/viewtopic.php?t=7198
Here's a partial list:
http://support.sourcegear.com/viewtopic.php?t=7198
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
-
- Posts: 52
- Joined: Wed Jul 12, 2006 5:38 am
I've seen this list, nice to see bugs are solved.
Shame that it takes so long.
Let's leave it at that, if there's no room for improvement and I'm basically talking to a brick wall (I don't read any recognition or even interest in your replies), there's no point in continuing this thread.
Regards, M. Wickardt
Shame that it takes so long.
Let's leave it at that, if there's no room for improvement and I'm basically talking to a brick wall (I don't read any recognition or even interest in your replies), there's no point in continuing this thread.
Regards, M. Wickardt
Don't quit on the thread just yet.
I know people have been waiting for this release, but it turns out testing has been quite an issue. The different combinations of Vista versions and 32/64-bit have increased testing time for Vault.
If anyone is feeling adventuresome, we will be looking for Beta Testers for the Vault 3.5.2. Any interested parties should contact us by email at "vaultbeta at sourcegear.com".
I know people have been waiting for this release, but it turns out testing has been quite an issue. The different combinations of Vista versions and 32/64-bit have increased testing time for Vault.
If anyone is feeling adventuresome, we will be looking for Beta Testers for the Vault 3.5.2. Any interested parties should contact us by email at "vaultbeta at sourcegear.com".
Jeff Clausius
SourceGear
SourceGear
-
- Posts: 52
- Joined: Wed Jul 12, 2006 5:38 am
I certainly understand that. But saying 'there really isn't much to change' just bypasses the question. You could for example shorten the development cycle length, limit the number of bugfixes in a release, always strife for a minor release once a month (or once every two months). You don't give me a reason why there 'isn't much' to change. I give you a reason there is.jclausius wrote:[q-uote="M Wickardt"][snip] ... I hope you will change this in the future.
Regards, M. Wickardt[/q-uote]There really isn't much to change.
Just to make sure everyone understands, M. Wickardt described our development model.
We'd like to participate in the beta testing, which we ofcourse won't be using in a production environment. I've sent an e-mail, thank you for the opportunity/possibility.
Best regards, M Wickardt.