SourceGear Support

I'm way ahead of you

Most interesting, indeed.

awdavis or Nikas: when you saw this, do you know if you were working with a shared folder?

Tri: Do you recall how you invoked the checkin - was it on a file, or a folder, or in the change set?

I've tweaked the request for filtering of obliterate and added a request for obliteration by date.

Thanks for the ideas - keep 'em coming.

Context menu "enablement" is already in the feature request list, and I bumped its priority up - we've had a number of requests for it.

Not to menion that it's a really good idea.

One other thing that might help: You can do a recursive get with the command line client using the -soshome parameter and -verbose. If you pipe the output to a file, it's not too painful to pick through it for non-inherited working folders. The command would look something like: soscmd -command getp...

I'm afraid I haven't been able to reprouce the first problem. Are the added projects new or do they pre-exist? Could you provide a step-by-step exaple of the process you use to manifest this problem? Also, could you clarify the second issue? On the checkin, the files should be set to read-only... or...

Yeah... it looks like there's a bug where non-modified files' keywords are not updated. It's been logged, but for the short term, the only way around this is to make a trivial change to each affected file.

Sorry for the bad news.

You can run different versions of the clinet on the same machine, but they'll share registry entries, so some odd things may happen due to changes in what is actutally stored in the registry by different versions. You should be able to install 1.2.3 and copy the folder holding the Vault executable t...

We'll have to plead "guilty" here. As currently designed, there's no way to view an item comment that displays the line breaks, apart from bringing up the edit dialog from history details. I have logged a bug for the line breaks to be retained, but the only way they'll be able to be seen i...

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 simi...

I just posted a quick reply on the main forum:

http://support.sourcegear.com/viewtopic ... 1641#11641

I'll continue following up over there, as it will have a wider audience.

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 think I've been able to reproduce it, but I can only get it to happen when copying text for a second time. My method looks like this: 1. Create a file with a couple of thousand lines. 2. Make an edit 3. Invoke a show differences 4. Select a large number of lines (> 1000) 5. control-C 6. control-C ...

Nope - IIS is not required at all. The SOS server is completely stand-alone.

That is rather irritating, come to think of it. I have indeed added it to the bug database.

And thanks for the easy one!