Problem using -getlabel from command line
Moderator: SourceGear
Problem using -getlabel from command line
Hi there,
We're using v3.0.2, and having a problem when we use the -getlabel command.
We've tested the following, which I hope illustrates what we're seeing.
File A, v1 - no label
-we do getlabel on label 'foo' - no file returned, as expected
File A, v2 - label 'foo'
-we do getlabel on label 'foo' - v2 returned, as expected
File A, v3 - no label (but v2 still labelled 'foo')
-we do getlabel on label 'foo' - v3 returned - NOT v2 AS EXPECTED!
Any thoughts on this, or am I missing something??
oafcmetty
We're using v3.0.2, and having a problem when we use the -getlabel command.
We've tested the following, which I hope illustrates what we're seeing.
File A, v1 - no label
-we do getlabel on label 'foo' - no file returned, as expected
File A, v2 - label 'foo'
-we do getlabel on label 'foo' - v2 returned, as expected
File A, v3 - no label (but v2 still labelled 'foo')
-we do getlabel on label 'foo' - v3 returned - NOT v2 AS EXPECTED!
Any thoughts on this, or am I missing something??
oafcmetty
I've confirmed that there's a problem with CLC getlabels when the label has been applied to a file, but I'm still trying to pin it down more preciesely, as I'm getting differing results with gets that specify the parent, and a couple of other wrinkles.
I'll post again when I know more.
I'll post again when I know more.
Brody Finney
SourceGear QA Thug
"I break things for a living"
SourceGear QA Thug
"I break things for a living"
At first I thought we had an "across the board" problem with CLC getlabels on labelled files, but it looks like the problem exists only when the command specifies the repositorypath of the parent (or higher ancestor) directory. In my initial testing I foolishly used a -destpath highly similar to my working folder location, so I think at times I was looking at the wrong file.
Since then I've done a half-dozen additional tests that indicate that getlabel operations get the proper labeled version when the repositorypath points directly at the labeled file rather than an ancestor.
If the behavior you're seeing is different, let me know and we'll dig a little deeper. I've logged it against 3.0.3, so it's nearly a surefire bet to be taken care of in the next release.
Since then I've done a half-dozen additional tests that indicate that getlabel operations get the proper labeled version when the repositorypath points directly at the labeled file rather than an ancestor.
If the behavior you're seeing is different, let me know and we'll dig a little deeper. I've logged it against 3.0.3, so it's nearly a surefire bet to be taken care of in the next release.
Brody Finney
SourceGear QA Thug
"I break things for a living"
SourceGear QA Thug
"I break things for a living"
Hi,
Yes I believe you are correct. When I point my -getlabel at an individual file, the command behaves as expected.
However, this doesn't really help us too much as we're building a project (using Visual Build Pro) containing around 7,500 files. As you would expect, we're not too keen on specifying all of those files in our VBPro Get Label command
Do you have an expected release date for 3.0.3? Alternatively, is there a chance of getting a patch or hotfix which may help with this?
Regards,
oafcmetty
Yes I believe you are correct. When I point my -getlabel at an individual file, the command behaves as expected.
However, this doesn't really help us too much as we're building a project (using Visual Build Pro) containing around 7,500 files. As you would expect, we're not too keen on specifying all of those files in our VBPro Get Label command
Do you have an expected release date for 3.0.3? Alternatively, is there a chance of getting a patch or hotfix which may help with this?
Regards,
oafcmetty