I haven't use sourcesafe for years and I don't konw which stage sourcesafe is currently at, but I want to point out onethinf about the branching and merging feature. Please check ClearCase Client. It has a great feature to visualize branching and merging in a version tree. If user wants to merge the code from one node to another one, he just need to click the first node and draw a line to another node. If Clease Case can't automatically merge the code, it will popup a window that display three subwindows is a row. The subwindows display content of first, second and merged code. It is very helpful for user to merge manually.

My biggest gripe about source safe is in sharing, which I suppose is tightly related to branch and merge. I want to be able to share a file across projects, and have different security rights for each project. IE, I can get the latest version, but cant check in changes. Or you can check in changes, but they have to be approved by someone.

My gripe (and something you can fix for the current release) is in the semantics of the workding in the dialogs. When merging code FROM a branch INTO another branch, the source and target are very unclear. You guys should look at the way Vault handles branch and merge...very slick. They guide you through it using a wizard that clearly identifies the source and target. Also, there should be a way to do a "collapsing merge". That is, I no longer want to see the branch in VSS after the merge back into the trunk.

Ditto on Chrisian Romney's "collapsing merge" and unclear process for branch/merge. I would love to see these improved.

A couple requests:
1. Bug: After a share+pin+branch operation (recommended by the docs) you aren't allowed to branch a file in the branched project if someone has it checked out in the main project. This really puts a crimp in doing any type of parallel development.
2. Usability: Having to "Cancel" a search filter is just silly. I can't tell you the number of times I've had a search filter active and then clicked on a folder... and there it goes searching again. Ugh.

Thanks.

Something like following one would be quite useful for branched projects:

http://www.shitalshah.com/utilities.aspx#DiffAnalyzer

Thank you all for your comments. I wanted to respond to some issues that were brought up.

Wht mentions support for visual merging. There already is some support for visual merging in VSS6, and this will improve in VSS 2005. If you select a project and do show differences on it, the default is to compare it to its working folder. It is possible, though, to change the compare to location to another project in the database. This allows you to see which files are changed. You can also select a file in the project diff dialog and compare its contents in the two projects.

When you merge a file from one project to another, the operation is similar to a checkin. Normally a visual merge dialog will come up if there are conflicts. You can also go to Tools | Options | General and set Use Visual Merge to Yes. This causes the visual merge window to come up for all changed files even if there is no conflict. The visual merge window allows you to select changes from either or both files. The merged version shows up in a panel at the bottom of the window. The changes are also editable.

Jason raises an issue of varying access rights for shared files. VSS does allow you to set access privileges by folder and user, but I suspect what you're really looking for is file level access rights. The scenario usually proposed is to have some shared files that can only be modified in one particular project. Users would not be able to change these files in other projects that they are shared to, although they might be able to change other files in those projects. We won't be supporting file level access rights in VSS 2005, but we are aware of the need, and it may show up in a later release.

Christian mentions that some of the wording in dialog is very unclear. We've made some wording changes for VSS 2005 that should improve this, but it sounds like a wizard approach might be better. This won't happen for the next release, but we'll definitely consider it for future releases.

Christian and Dave also mention "collapsing merge". Would simply deleting the branch project when you're done meet your requirements? As long as you don't destroy it, you can always recover it if need be.

Dave also mentions not being able to branch a pinned file that's checked out in another project. I'm opening a bug on this, and I hope we'll be able to fix it in VSS 2005.

Shital shares his application to compare file in two projects, show some statistics on differences, and bring up a diff report based, I believe, on the VSS command line utility. VSS 2005 will have the ability to launch the SourceSafe diff and merge viewer from the ssexp command line. This will allow some additional flexibility in doing custom diff and merge viewing.

I'm also investigating a merge bug that wasn't mentioned. Currently we don't keep track of the basis version when merges happen. For example if a file is branched at version 2, then this is the basis version. If we make changes in one of both of the projects this file is in, then when we do a merge, we compare the diffs from where we branched the file (version 2). We then check in the merged file to the project we're merging into. This checkin should then be the basis for the next merge, but we don't currently keep track of this. Instead we always compare diffs from the branch version, and this can lead to unexpected merge results. This makes merging branches not very effective beyond the first merge. Our intention is to fix this bug, and we'll also look at the problem of branching a pinned file that's checked out elsewhere. We'll also look at project level merges, but this can be done already from the command line, so supporting this in the UI may not make the cut for VSS 2005.

I hope you guys dump that /data/a/aaaaaaaa.a file system format... and use SQL server for access, because over a VPN connection, VSS really sucks... its too chatty, because it has to depend on the clients to manage the database [bad idea, IMO]

another thing,

file/directory renames: these things have got to make it, and be able to propogate to the other team members effectively...

i believe this means ditching the current SSAPI and developing a much more in-depth API.

You mention that it is possible to do project-level merges from the command-line.

In VSS 6, that's is very awkward as the command-line does not work recursively (can only do *.* in the current project). Has this changed in VSS2005?

Re branching - it's very difficult in 6.0 if the project uses Visual Studio integration.

Integration adds links to the physical VSS file into the .dsp files. When the project is branched, these links are not updated. So a checkout+checkin from the branch will update the original project - not a good thing.

When using the share + pin then branch method, the history for pinned files in the project branch shows all the changes made to the file in the trunk. This makes it difficult to get a clear picture of the changes that have occurred in the project branch as the trunk changes have to be weeded out.

Once a shared file is pinned, its history should only contain changes up to the version at which it was pinned and not any subsequent changes.

The last time I tried, I seemed to require change access to a project/file in order to branch it. It seems to me that I should be able to generate a branch off of a project that I only have read access to.

When I branch a project, the branch does not inherit any of the labels in the original project. The change history is there, but the labels are not.

The Properties dialog for files needs to be sizeable. In the "Paths" page, if the nesting becomes very deep, all the interesting data gets clipped on the right side.

Also, I've seen cases where the "Links" page contains "..." in the pathnames, so you cannot tell the entries apart.

When I share a project by right-button dragging it, I get a popup that allows "Share", "share and branch", or "Move". If I select either share option, I get a dialog asking for the new name for the project. This is all fine.

My complaint is that it does not allow me to use this operation to create a sibling of the original project. To create a new project with the same parent as the original, I need to first share to a different place in the tree, then "Move" it into the place I want it. Since I'm asked for a new name anyway, there shouldn't be a problem allowing me to use the original project's parent as the drop location.

"Share and Branch" will create a new project, and branch each file in the tree. However, if I just do a "Share", there is no convenient way to subsequently branch all the files; I have to do them one-by-one.

An option to recursively branch all the files in a project would really be helpful. Presumably, this would only apply to the files in the tree that are currently shared.

To save space, we use the "Store only latest version" on binary files (i.e., PDF files) that are manufactured in a different context. We put these binaries in our source tree to to aid an building our software releases, and to track the manuals that correspond with the releases.

However, the "Store only latest version" and and pinning are mutually-exclusive features. Thus, we cannot use the "pinning and branching" technique to do branch development, we need to use "Share and branch".

It would be helpful if "Store only lates version" would also keep pinned versions. This would allow us to use both features.

First, I'd like to second Dave Tillman's comments about sizable dialogs (I sent you a message about this a couple of weeks ago through the contact link). At the very least, allow for horizontal scrolling in listbox for the links/paths tabs and get rid of the '...'

Second, the idea of recursively branching files could be refined to not branch files that are shared within the tree in question (i.e. if a file is shared both out of the tree and also shared within the tree, branch from the outside version, but leave the internal share intact)

Third, if a shared file is only shared to deleted versions, either don't show the share icon (It just looks like clutter) or use a different icon. The visual annoyance has led us to purge deleted projects that we would have otherwise kept.

Finally, If a file is pinned, and a recursive get is performed on the tree from a label that was applied later than the pin either get the pinned file automatically, or add a command line option to get pinned files. The current behavior makes pinned files in the trunk next to worthless if you have an automated build process.

Currently VSS doesnt allow multiple labels for the same internal version of a file. It would be very helpful for making builds if this feature can be added.

The ability to find files available for (and thus needing) merge needs to be improved. You mention that you can compare two SourceSafe directories and find what files have changes that way. But you can't do anything to those changes, which means you'll have to close the Diff window, perform the merge, and then redo the diff to check status/find more files for merge. Either that, or manually track the files to be merged (which is a tiresome task that really should be unnecessary).

You mention better support for visual diff/merge in 2005, I hope this function is included.

Mail feature in VSS -

Hi, I am Richard and I was thinking if you could have a mail feature embedded in the VSS to enhance the product performance in case of branching and merging issues come up. The VSS handler can mail the developers / testers and the program manager if required.

This is just a thought. Feel free touch base me at bjrichard@rediffmail.com

Regards,
John Richard

As far as I know, you seem to have "forgotten" the pin/unpin functionality in the API.

In total, the API is rather strange, with a somewhat unclear object model, where you can get to the same objects in different ways, but where the available methods and properties differs depending on how you fetched the object.

Will there be a overhaul of programmability issues?

In our flight simulator department we use SourceSafe to track changes to our visual models which are used on each of our flight simulator's image generators. Our visual models are authored using MultiGen 2.21 (http://www.multigen.com) as a type of binary file called "openflight" which is then converted to a format suitable for use on our image generators. Visual SourceSafe has proven to be a full-featured product which will handle and keep track of "binary" files. I would suggest you work to retain Visual SourceSafe's ability to handle large "binary" files and do not remove this feature from future product versions.

And, since this has turned more and more into a "What in general could be improved in VSS"-thread (what'd you expect?), I'll add another feature request: version control of directories (a.k.a. "projects"). This is invaluable to long-term projects. I guess it's s bit difficult to get into for VSS, CVS or PVCS people, but once you get to know it, you can't live without it ;)

First, let me say please forgive me if you can do these things now. I suggest them because I can't get VSS 6 to do them.

1. It would be nice to configure VSS to prompt for a description of changes for *each* file it determines has changed, everytime files are checked in.

2. I would also like to see the "lable" feature changed to manage version numbers automatically. I use the label feature to designate a certain revision as "V1.12" for example. Unfortunately I have to manage the number manually, using history. I would prefer to be prompted "label as next minor revision or major revision", as an option with text labeling.

3. I would like to have meta commands in my source code that would be "filled in" by VSS on check-in/check out. This might include revision number, label text, last check in date, last checkout date, etc.

Thank you,

Gary Treible

Sharing and branching could be made vastly more useful by adding a lock/unlock facility on files and projects.

The current share/pin/branch model works when primary development is on the new product, and a small amount of work is going into bug-fixing the "1.0" version. But when it's the other way around - most of the work is on the existing product, while a small beta team works on new features, there is no way to use the current share/pin/branch system effectively.

This could be remedied by adding a simple lock feature. A locked file would be read-only and could not be checked out until unlocked.

Prior to starting the new "beta" development branch, you would share all the files, then lock all the shared "copies". It would need to be possible to lock just the shared version and not the files in the original project. This would have the same effect as pinning - except the 'pin' would always point to the latest version. So when bug fixes are made in the main system, the latest bug-fixed files would automatically find their way into the beta version. However when a beta developer attempts to check out a shared (and locked) file, they would be prevented from doing so since their beta modifications would also affect the main version. Instead at that point they would branch the file. Branching should be possible on a locked file without further prompting.

Another good feature to add would be an optional warning generated whenever a branched file is checked in. Probably best on a file-by-file basis. This would alert the developer that the change may have to be reflected in the other branch copy. There would need to be some mechanism by which this would get back to Visual Studio, if checking in via SourceSafe integration.

Obviously this should not applied if the branched file has been deleted.

If info regarding branching and pinning was available via the automation interface that would be a major bonus. Presently the automation interface excludes some information, most notably branching.

This comment does not relate to branch and merge - but it may be worthy of another blog thread.

We use source safe to manage our web deployment. We have a four stage cascade deployment process. Development, Staging, Certification, Production. On thing that is very useful is the web deploy feature - but I think it could be improved. The features I would really like to see for web deploy are as follows:

- Right click on any item to access the web deploy feature
- Ability to deploy to more than one web server (with above right click function)

The second option would be a real bonus for us because we could right hand click and deploy directly to Development, Staging or Certification (rather than have to constantly flick back and forth between ftp / source safe / text editor)

Any thoughts anyone?

For us, this is too late - due to limited merging capability, we've just moved to using SourceGear Vault. One extremely annoying thing about Vss is window size - Could the "share" window possibly be any smaller?!?! Also - long path/file names are trucated at the beginning so one can't tell where a file was branched or shared from. Also - when you add a new file to a shared project, it isn't automatically added to the other project folder. Vss DB size is limited. Vss is very slow when DB size goes above 8 GB. I know your supposed to limit DB size to 3 - 5 GB - but that's too small for our needs.

I have a comment on Sourcesafe label feature. I think it deserves its own thread. When you label in sourcesafe, you are labeling the current snapshot in VSS database, not the snapshot you retrieved to your PC. This makes big difference when you have big teams working on different pieces of code and a build team promoting each team's code to "workingset" label. They find a problem with some functionality. The owner might change and check in anew file which the build team picks and tests the whole build again. When ready, the build team wants to tag the version that they retrieved on to their disk with a label (not the snapshot of vss databse when they are ready after testing the build). I don't think there is a way for doing this on sourcesafe. Thats a feature I like about CVS (besides dozen things I don't like about it). Sourcesafe should provide this kind of label feature.

Hello,
We don't know why MS decided ONLY NOW to make improvement to Source Safe... this product was apparently sleeping for long and may be the users has switch to another tool.

We requested full unicode support with files
(included GUI diff merge and files stored in the base )

It would be nice to get some speed increasement on some actions ex doing history & doing branch on big tree

It would be nice that VSS could handle grouped check in of multiples files ( easier to restore a point when working on bugs in team)

It would be nice that the problem of the .dsp files could be solved when you branch becausethe check out are missed done . acctually you have to manually clean the vss info in the .dsp and relink after...

...br

Can anyone let me know if there a way in sourcesafe to merge specific versions of a file on different branches. Say for instance that I have the following.

aaaaaaaaaaaa.txt version 1
aaaaaaaaaaaa.txt version 2
aaaaaaaaaaaa.txt version 3
aaaaaaaaaaaa.txt version 4

Then at Version 4 the file is branched at version 6. and it gets changed as follows.

aaaaaaaaaaaa.txt version 5
aaaaaaaaaaaa.txt version 6
aaaaaaaaaaaa.txt version 7
aaaaaaaaaaaa.txt version 8


Is it possible to merge specific Versions into a new aaaaaaaaaaaa.txt version 9 ???


Many Thanks
Warren
warren.birch@3mex.com

hello sir
i just test VSS2005 from beta1 cd august2004
and no way to use customized diff tool
as in VSS6.0 ?

i think it is best to propose a customization
way for editor / diff / merge tools...

tester

PingBack from http://insomniacuresite.info/story.php?id=1729

PingBack from http://edebtsettlementprogram.info/story.php?id=22986

PingBack from http://workfromhomecareer.info/story.php?id=21357