Is branching in Vault lazy?

ENovales · Post by **ENovales** » Mon Mar 01, 2004 4:11 pm

By "lazy," I mean that the branched files are only actually duplicated once a change is made on the branch. This lends itself well to frequent branches (perhaps even bug-specific branches). So...yeah, is the branching in Vault lazy, or is it basically the same way SS does it?

Thanks in advance.

Post by **jclausius** » Mon Mar 01, 2004 4:16 pm

yes. in vault 2.0, what you call lazy, we call "light-weight".

i'm not certain how ss handles these cases.

hth

sterwill · Post by **sterwill** » Mon Mar 01, 2004 6:17 pm

Something to keep in mind is that although branches are pretty light-weight in the database, they do cause your repository tree structure to grow, and this new structure data must be sent to the clients. If you have clients connecting to servers over slow links, you'll probably want to try to keep your tree size from growing by large amounts often.

Thomas Linder Puls · Post by **Thomas Linder Puls** » Fri Oct 29, 2004 5:18 pm

I am sure this will become a major performance issue for us. We already suffer from large cache files (>20MB). I can tell you that it is not nice to wait for the synchronization of the repository structure on a slow (<1Mbit/s) WAN line.

So far we have not branched a single release, but I imagine that we someday will have at least 10 complete branches. I believe this will increase the cache 11 times. This is not nice, especially considering that I practically never need the structure of the released branches.

I think it would be a good idea not to have the structure of cloaked files cached. Or at least only update that part when really needed.

dan · Post by **dan** » Mon Nov 01, 2004 8:54 am

We only send the changes between tree versions for refreshes, so you would only take a hit sending info to the client right after a branch occurs. So, this normally won't be a problem...

Thomas Linder Puls · Post by **Thomas Linder Puls** » Mon Nov 01, 2004 9:32 am

If what you branch is >30.000 files then I can assure you that it matters.

Anyway we have decided that the performance of Vault with many files (>100.000) in the repository is not satisfactory, so we no longer use Vault for our test suite (which is the one uses many files).

If you like I can send you our test suite, then you can add it to Vault and see the performance yourself (that is if you can add it at all, I had to add it in several smaller chunks).

dan · Post by **dan** » Mon Nov 01, 2004 10:13 am

Sure - we always like to see real user data. Send me an email and a place where I can download it from and we'll use it to see what you are seeing.

Thomas Linder Puls · Post by **Thomas Linder Puls** » Thu Nov 25, 2004 2:44 am

Hi Dan, now you have had the files for long time. So it would be interesting to hear:

What is the performance effect of branching >30.000 files?
Try locking >30.000 files. What influence does it have on performance (especially logon time)? Notice the size of your cache files.

If you have the poissibility, to see how much data you transfer over the network, then you will (especially in the case with many locks) be able to see that a very fast connnection is needed

.

Is the performance on these matters (significantly) better in Vault 3.0?

By the way when is 3.0 released?