File Sharing Question / Feature Request

kellyb · Post by **kellyb** » Thu Feb 17, 2005 9:59 am

I've been hestitant to utilize some of the advanced features of Vault - mainly due to my back side still being a bit toasty from years of VSS burn. Eric instilled courage for me with:

http://support.sourcegear.com/viewtopic ... d+features

Today, I went to explore the File Sharing features of my Vault product. Before I get into the problem I've ran into, let me explain my usage of Vault and branching.

We are using Vault as the source control platform for a living commerical software product. In other words, like Sourcegear, we have a living "Main Trunk" in our tree that is brached wtih each of our releases. This feature in Vault has been very good to us so far and we have been very happy with the merging capabilities. These features were our main motivation to move to Vault [respectful applause].

Recently, we have identified a number of files in our application that need to exist in a static fasion across all releases. For example, we have an xml file that defines UI error messages. We want to have this file living on it's own and used by all releases. As a change is made to this file in one release, all releases (and the "Main Trunk") automatically get the change.

The logical candidate in my mind is File Sharing (please correct me if I'm wrong). I went to Vault and started playing with the feature to make sure it behaves exactly the way I want it to (again, backside is toasty). I ran into something that I don't like and is going to be a barrier for us.

From the Vault Help file: "Shared files and folders are no longer shared when there is only one link remaining after a Branch or Delete command. Once all share links have been deleted or branched, the file is no longer shared. See Branch Items for more information."

According to this (confirmed by my playing), each time I branch our "Main Trunk" and it's shared files the "links" are servered. So, I need to go in and re-share each file from its original common location into our newly branched release.

That in itself is disappointing, but I could live with it. What is going to be a major problem is that in the scenario I described above, when I do do that branch, it clones the shared files right along with everything else, though they are no long linked in any way to it originator. They are "dead files". Actually, worst yet... they are alive, but rogue. If I miss something this manual process of deleting and re-sharing when we do a release, one of my developers will be confidently checking out that xml file from this release world and check it back it, but it's not going to take effect where I want it to (across all the releases).

Is that correct? Am I missing something or is there a way to go about this that avoids this behavior? Assumming I'm understanding all this correctly, is there a reason why Vault doesn't atleast warn me that I'm about to clone some dead files? Or even better, ask me if I want to re-share them?

I don't mean to sound negative... I'm a huge Vault fan - you guys rock, but I was disappointed by this.

Post by **jclausius** » Thu Feb 17, 2005 10:26 am

Kelly:

An excerpt from the help - "Branching a folder maintains shares between files and subfolders that are self-contained within the branch, but breaks shares to any link outside the new branch."

So, let's use an example:

$/
$/trunk/
$/trunk/src/A/
$/trunk/src/A/file1.cs
$/trunk/src/B/
$/trunk/src/B/file1.cs

Where file1.cs is shared.

Now I'm going to branch trunk:

$/
$/branch/
$/branch/src/A/
$/branch/src/A/file1.cs
$/branch/src/B/
$/branch/src/B/file1.cs

So now, there are two sets of shared files: file1.cs down $/trunk/ and file1.cs down the $/branch/. So the shared files down a particlar part of the tree are maintained.

Since this is a branch, a change in one should not be "automatically" be reflected in the other. However, when changes are committed to one of the file1.cs, you may wish to move those changes to the "other side" of the branch. you would use Merge Branches to migrate the information into the other set of files.

Does that explanation help your situation?

kellyb · Post by **kellyb** » Thu Feb 17, 2005 10:45 am

I don't think we're on the same page. Perhaps I'm misunderstanding, but the whole point of a shared file is the "automatically" part.

i.e. "Any change made to the file or folder in any of its shared locations will be reflected in all locations after the change is made."

The example I have in mind is

$/Common
$/Common/someFileToBeShared.txt

and

$/Trunk
$/Trunk/someFileToBeShared.txt (this got here from $/Common)

we do a release and branch the trunk:

$/Release 1.0
$/Release 1.0/someFileToBeShared.txt (rogue file)

If a developer on my team assigned to Release 1.0 maintenance makes a change to someFileToBeShared.txt in Release 1.0, it's not in $/Common. The reverse is true. If I make a change to $/Common/someFileToBeShared.txt, that won't be showing up in $/Release 1.0.

I want to have a place that is common to all my release (branches) and each time I branch (release the software) that shared relationship is maintained. If I can't have that, its not the end of the world, but I don't want rogue files hanging around from the severing process.

Does that make sense or is my head up my #*$(@?

Post by **jclausius** » Thu Feb 17, 2005 11:43 am

kellyb wrote:If a developer on my team assigned to Release 1.0 maintenance makes a change to someFileToBeShared.txt in Release 1.0, it's not in $/Common. The reverse is true. If I make a change to $/Common/someFileToBeShared.txt, that won't be showing up in $/Release 1.0.

That is correct. The definition of a branched folder is to create a distinct folder based on the files / folders found in the source trunk. The separation prevents any "automatic" changes in the branch from making it back into the source trunk without intervention. However, when changes are wished to be "migrated" to the trunk, invoking "Merge Branches" from the Tools menu will propagate the change.

kellyb wrote:...I don't want rogue files hanging around from the severing process.

I don't know if I would consider the file(s) "rogue". They were a stable part of a folder's version for a given point in time. If the file was not found in the branch, then that part of the branch has some instability. In other words, if a branch is created for Release 1.0, and work starts in someFileToBeShared.txt for Version 2.0, the branch keeps the file "fixed" at Release 1.0 so the file is in a known stable state - builds work, the file is stored as it relates to Release 1.0.

Now, when the changes in someFileToBeShared.txt are ready to be placed back into Version 2.0, they are migrated using the Merge Branches tool.

I don't want to stop anyone from working in their own fashion, but it is possible this situation may have a work-around. If you kept all the common files in one folder, you could shared the folder in different main line folders. Then upon the branch, the newly created "unshared" folder within the branch could be deleted, and the "shared" common folder shared into the correct place within the branch. Not pretty, but I believe that might work.

kellyb · Post by **kellyb** » Thu Feb 17, 2005 12:52 pm

The wholel motivation for what we're tryin to do is NOT tie someFileToBeShare.txt to any folder of the trunk or its branches. I want someFileToBeShared.txt to be outside of all of it and it's changes to be reflected in every single location it shared to. And when a location it's branched, I want that relationship maintained.

Let's just say that I have a legit case where I want a handful of files to be static across ALL of my release branches. I fully understand that that is not the purpose of "branching". Branching creates a standalone clone of the files it originated from. That's cool - I've got that. What I'm sayign is... if the files that a branch is created from contains a file that is being shared from some other location, I want the "share" to be cloned and the relationship to be carried down to the new branch - not just take a copy of that file. To me that is "rogue", because the source that file was branched from is "virtual". it's a shared file form another location. You guys call it the "Secondary Share" I believe.

I think I understand where you're coming from and why it is the way it is.

Sharing doesn't solve my problem. I need to think about it some more

Post by **jclausius** » Thu Feb 17, 2005 1:16 pm

I think the only way to achieve what you have asked is to look at my work-around posted above - share back into the newly created branch.

Out of curiousity, is there a reason for not using the merge branches feature to migrate changes in release 1.0/ back into trunk? Is the problem those changes are not automatically merged?

kellyb · Post by **kellyb** » Thu Feb 17, 2005 2:05 pm

The problem is the contents of this particular file. It's not something that I probably would have done with hindsight on my side, but they are XML files that contain number sequences. Each node an identifying number. When new nodes are added by our developers they take the next number in the sequence as the ID. So, when concurrent development is going on, there is a strong chance for a conflict in the numbering sequence.

Now, there are other ways to manage this of course. The way we do thing, its very hard to block out number ranges because the needed range is unknown and dependent on the given release. Yes, we could over shoot the range and probably be safe, but that will get out of control quickly (very large numbers).

There are other approaches of course, but my initial reaction was this was something Sharing could do for me quickly and easily, but having thought about it more, it makes perfect sense that the shared relationship is broken at the time of the branch.

In the case of merging... well, that really doesn't solve our problem as you can see, because the number sequence is the root problem. What compounds the problem is that our application code is dependent on these ID's.... so if you re-sequence the numbering, you're gonna blow the code.

This is quickly getting into an architecture weakness issue....

Post by **jclausius** » Thu Feb 17, 2005 2:19 pm

Ahh.. I see why this presents a problem. Sorry, I don't have much more to offer than my painful work-around.