Pending Change Set in CVS Mode is not up to date

[PACEGMBH]

Would'nt it be possible to force the update recursively if we push F5 on a top level folder? It works for the time beeing only on the selected folder but not recursively.

[dan]

The problem there is that scanning all the folders can take quite a long time, depending on how many working folders you have defined, how slow your disk is. A refresh should be a fast operation, so we didn't want to bog it down with a file system rescan.

So, we put in this "hidden" scan on the currently selected folder on a checkin from the context menu as a way to enforce the scan on a selected set of working folders. We could add a separate command, but we are sensitive to command overload, especially if it isn't clear what the command does to most people.

[PACEGMBH]

I think it is not so unlikely to set multiple repositories to use the same working folder. I've seen some other projects, which go the same way at least for some of their source files. And since the vault allows setting the same working directory you seem not to limit the use at this part.

As I said in my first posting I personally could imagine 3 solutions. Beside the correct recognition and the explicit refresh also the incorporation of the search result from the search page. There are all changes detected if you search for instance for edited or any status.

The 'check in' work around that you describe is not sufficient. Since we work in cvs mode, we do not check out and hence do not have the 'check in' possibility on the folder level unless vault has already found edited files. Otherwise 'check in' is not sensitive.

[ericsink]

I'm taking Dan's place in this conversation.

Hopefully the disruption will be minimal. I am basically familiar with the issues here. I just want to understand the usage scenario better.

Let me start by telling you my current position. I believe you have found a bug in Vault, one which I consider quite important. But I don't think the bug I see is the one you want fixed. The bug I see is this:

Vault should never allow one local disk folder to be set as the working folder for more than one repository folder.

This strikes me as a terrible idea, one which can lead only to problems and unexpected behavior.

You have found one way in which this approach doesn't work as you expect. I'm surprised you found only one. In fact, I am shocked that it works at all.

Dan asked me what I thought about fixing the bug you reported, and I said "Absolutely we should fix it -- Vault should throw up a big error message whenever a user does what this customer is doing". He pointed out that this is probably not what you want.

So it's time for me to listen to more of your perspective. There appears to be something I don't understand. You find it useful to configure multiple repository folders with the same working folder. Could you tell me why? Include lots of specifics if you can.

I'm willing to consider supporting the decision to make this use case work, but first I need to understand it.

[PACEGMBH]

Hi Eric,

nice to here from you. If you fix the BUG which in the way you intend at the moment, this would certainly a big problem for us
Sad, there Dan is right.
Since a long tome we have used SourceSafe, but with the growing repository size we’ve got more and more problems, partly with loss of data, not to speak about concurrent access to sources. So we had the need to switch to a more robust tool. Unfortunately we have over years a huge bunch of sources, all structured in the following way:

Code: Select all

Module
	Vcproj file of the module
	Configuration
		Modules
			ModuleName
				Module configuration files
	Data
Modules
			ModuleName
				Module data files
	Database
		Modules
			ModuleName
				Module file based DB
	Locale
		Locale_en
			Module Language Resource files
	Modules
		ModuleName
			Module Source Files
	Resource
		ModuleName
			Module Resource Files

Each of our 80 different modules is structured this way, but not all of them implement all parts of the structure (e.g. leaving out Database). All modules potentially have the same working directory.

This structure was well supported by SourceSafe.
It automatically places files that are related by their kind in a common location.

When we made an evaluation of different SourceControl tools we recognized, that many of them have a problem with this structure. So the Support of such a structure was one of the selection criteria among others:

• - Database support
  - Transaction based commits
  - Support of VSS and CVS mode
  - IDE integration
  - Costs

Our candidates have been Perforce, SourcegearVault and Subversion.
Vault was the only application which seemed to support our directory/repository layout, so it saved us a lot of money and especially time for the restructuring of our sources. I know that there are other good reasons for a restructuring, but finally we found nobody who was willing to pay for all the work and to give us some time to do it


For our new projects we have changed the structure to a more component based one. But also here we have some cases, where we use the same directories for some files originating of different repository folders. This is the case e.g. for solution files originating from different products, which are brought together at the top level folder of the final product to build. Therefore all of our solution files are located in the top level folder above the component level.

Where the repository layout might look like this:

Code: Select all

$
	Products
		Product_A
			Product_A.sln
			src
				Component_1
				Component_2
		Product_B
			Product_B.sln
			src
				Component_3
				Component_4
	Shared Components
		Component_5
		Component_6

the directory structure for Product_A which uses Product_B might look like this:

Code: Select all

Product_A
	Product_A.sln
	Product_B.sln
	bin
	src
		Component_1
		Component_2
		Component_3
		Component_4
		Component_5
		Component_6

This also implies that the working folder of $/Product_A and $/Product_B are the same in case they point they point to folder Product_A on disk. Our build script for Product_A has to build the 2 solutions Product_B.sln and Product_A.sln one after another. This use case seems to me quite ‘normal’ for a lot of complex products, which do not want to use one single solution file.

Are these the information you need to understand our use cases?

Best regards,

Carsten.

[GregM]

Carsten, is it safe to assume that no two folders that share a working folder ever have files in them with the same name?

[PACEGMBH]

Absolutely! everything else could be considdered as a fault.

[ericsink]

OK, I think I get it now. My opinion of your usage has upgraded from "hopelessly vulgar" to "maybe kind of weird".

We'll look into this.

Thanks.

[PACEGMBH]

Hi Eric,

are ther any news about this topic? as you I (and many of my colleges) prefer the work with the vault client instead of the MS IDE integration, but the problem with the pending change set is really limmiting.
Isn't it possible to include one of my proposed solutions in the next release? What is the status?

best regards,

Carsten.

[ericsink]

This is item 10098 in our bug database. I'm not making any promises, but I have marked the item to remind us to give the matter some attention for the next release, which is Vault 3.5, which is scheduled to happen sometime in the next few months.

Thanks for the reminder.

[PACEGMBH]

Thanks,

I'm looking forward then to Vault 3.5!:D

[ismangil]

This is item 10098 in our bug database. I'm not making any promises, but I have marked the item to remind us to give the matter some attention for the next release, which is Vault 3.5, which is scheduled to happen sometime in the next few months.

Thanks for the reminder.

Really off topic here: I thought the next release was 4.0!

[dan]

There are 2 major features that will be ready well before other 4.0 features, so we decided to create a special release for them so folks can get their hands on them early. They are:

1. Archive/Restore tool (which we are calling theFolder Export/Import tool)
2. Fully supported Dreamweaver client (we've had previews up until now)

There will also be a few other goodies in 3.5:

• "ghosted" local files and folders in the Vault tree
  History Favorites
  More commands in the status search pane
  Faster folder diff
  Query by label in history
  Ability to edit a label comment
  Filter and sort in History by Version

One last note about 3.5: It will be a paid upgrade, so you'll either need to be up-to-date with gold support, or pay an upgrade cost.

[PACEGMBH]

Hi Eric,

before we change to vault 3.5 I want to ask if this issue(10098) was covered by the new version. Is the rescan button for the pending change set what we need to have an updated pending change set, even if multiple repository folders are mapped to a single working folder?

Thanks and best regards,

Carsten.

[jclausius]

Carsten:

before we change to vault 3.5 I want to ask if this issue(10098) was covered by the new version.

Bug 10098 was fixed, but that bug was limited to a single repository. Setting multiple working folders to multiple Folders across repositories will create problems for the Vault client because its state information will be corrupted on a refresh or get by the other repository.

However, this thread Vault 3.5 - Working folders has spawned a new feature request - Item: 10904 - "Ability to set multiple repository folders to the same working folder".

Is the rescan button for the pending change set what we need to have an updated pending change set...

A rescan button was added to the toolbar for Vault 3.5. Clicking this will force a scan of the current repositories working folders for changes.