I've recently migrated code off of a limping SourceSafe database to a fresh SourceSafe database. We're maintaining the old database to keep our version history, but I'd like to mark those files as obsolete, so other programmers don't get confused as to which version to use.
Does SourceSafe support any feature that lets me flag files as obsolete but keep them in the database?
You yourself, check all of the files out of the old source safe,
and they will come and ask you to check them back in.
At that point you can educate them.
delete option will do this for you. The file (and its) revision histories will remain in version reporitory but file itself wont be visible from current version onwards
Related
We use Entity Framework 5. Sometimes we find if we make a change to the model all class files are deleted and re-created, although most of them contain exactly the same code as before.
Subversion marks all these files as deleted/new and, when committed, uploads a new version of all of them, regardless of whether their contents have actually changed. This is annoying as it makes it difficult to track which files have actually changed.
Is there any way to make subversion include in the commit only those files that have actually changed?
We are using TortoiseSVN 1.7.11, Build 23600; and AnkhSVN 2.3.10838.1211 with Visual Studio Professional 2012
As workaround you can use subversion hooks and prohibit remove/add files with identical names in same revision. Then user will be responsible to convert 'replace' to 'modify'. This is also annoying, but will be better look in history, better merged and updated.
I am beset by my lot using VSS 2005 (8.0.50727.42) as source control, which I really struggle to get on with. I am proposing moving to SVN http://www.visualsvn.com/server/ and have found a tool which appears to do the migration along with pulling all the history across - in order to keep my fellows happy. - http://vsstosvn.codeplex.com/
(if anyone has had any success or experience with this would be interested to hear your thoughts)
however, in order to make sure this works I would like to do a trial run, but have no idea how to take a backup of the existing VSS in order to do so.. as this tool appears to also deal with changing all the source control bindings in the solution, so if it goes tits up I would probably be beaten..
can I simply make a copy of the folder structure in which the srcsafe.ini resides?
its just that seems to have all kinds of crap in its data folder..
folders called
a
b
c
etc..
any help much appreciated
thanks
I've used the VSS2SVN command line client in the past and it worked OK. I think it was hindered somewhat by how VSS had been abused (poor commit messages, commits to single sporadic files) so that the commit history was only loosely useful.
I can't remember how I worked it but it was probably just following the documentation for both VSS2SVN and VSS.
The documentation for Visual SourceSafe (appears to be the 2005 version going by the "What's new" pages) has instructions on how to backup and restore a VSS database with history. You can do it all from the administrator interface and restore to a new location, or there are command line clients to do it.
Notice the warning that users cannot be using the database while you make the backup and the analyze utility cannot run. This implies that it's probably just a simple file copy over the network with no protection or locking in the database. You'll probably need to schedule the backup around your users (it was OK when I done it as there was only three of us).
Edit: I've found a blog article which summarises the options for doing a VSS backup, which seems familiar so I might have referenced it when I performed our migration. The outcome of that is that yes you can just copy the directory with all the VSS information, but again you need to be sure that the database cannot be modified while it is being copied.
https://support.microsoft.com/en-us/kb/244016
Make sure that no one is using the database and that Analyze will not begin to run while you are backing up the database.
Copy the following folders:
\DATA
\Temp
\USERS
Copy the User.txt and Srcsafe.ini files.
When you follow this procedure, you can do a full restore of the database by replacing the existing Users, Temp and Data folders as well as the Users.txt and Srcsafe.ini files with the copied versions.
You can also use this procedure to move the database to another location by placing the copied files into a new folder. To open the database, on the File menu in the Visual SourceSafe Explorer, click Open SourceSafe Database to browse to the new location.
I come from a Microsoft background in coding and thus have been used to Team Foundation Server and such for source control. Under TFS the files would check out by themselves in Eclipse and I would check them in when I was finished.
I have installed Subversion and the connector into Eclipse and have created my project with a local server
On Subversion do I have to check out the file when I need to change it? It doesnt change the RW permissions so I am not sure what the procedure is.
So basically if I am using Subversion in Eclipse what is the procedure for checking out a file and checking it in? What buttons are clicked?
Thanks for any help!
No, you don't need to "check out" to enable editing a file in Subversion. Subversion does not use the same type of locking VSS does (and TFS, by the sound of it - though I haven't used TFS myself). The locking that svn uses is sometimes called optimistic locking. Here is the svn manual page on file sharing and locking with a lot more specific details.
In Subversion, you would update your working copy like you normally would, but without any additional steps you could then just begin performing your changes to any file in the working copy without needing to lock out any other users, and commit when ready. If no one has modified it since you updated, then it will just commit the changes. Even if someone has, it will still commit (provided the same lines were not modified) and the server will handle it. If however, someone else modified the same lines of the file as you, then a conflict would occur and the commit would fail with "one or more files are in conflict". The conflict must then be manually looked at, eliminated, and marked as resolved, after which you would retry the commit and it would then go through (provided nothing else was in conflict).
Conflicts during every day work on a single branch are rare, which is why a lot of versioning systems use optimistic locking. Only when dealing with merging back and forth between branches do things sometimes get more involved.
Typically I would checkout the entire project, make my changes and then use the team sync view to review my code changes and commit from there. Right clicking is the key (see screenshots)
A great walk through on the basics can be viewed here.
Most of your actions will reside on under the Team menu; where you can commit, add, etc...
I use to use Subversion with eclipse. Now I use subversion with VSS. In both situations I've found I prefer, most of the time, to use Tortoise SVN for all my operations with the repository. Not as much of an answer but more of an opinion.
I need to keep under version some large files (some Gigs).
I don't need, and I can't keep under version all the version of the files.
I want to be able to remove from my VCS large files version at some moment.
The files that I want to keep under version control are big .zip files or ISO images.
These files may contains executable software or data (seismic data, SAR images, GNSS data) and they are provided by the software supplier of my company.
What control version system could I use?
In CVS you can do that by removing the files from the repo. Subversion allows that by dumping the content of the repo and filter it to remove the files (that is a bit cumbersome). Perforce has an obliterate command for that. Many of the newer distributed VCS make it rather difficult by their usage of hashes all over the places and the fact that your repo may have been replicated elsewhere also complicate things. Hg has a strip command (part of the Mq extension), Git can also do that I think.
I don’t think there’s any version control system that allows you do that regularly because that goes against everything version control systems stand for.
Perforce generally allows files to be put in two way, as head revision only (so, you'd only every have one copy) or all revisions. Perforce does have the admin level obliterate command that can be used to delete revisions. Its up to you to query for a list of files, possibly by date or number of revisions, and to specify the revisions to the obliterate command. As the name suggests obliterate deletes the revisions permanently from the database, so, I always generate scripts to do this and review them before running them. If the obliterate command is NOT run with the -Y flag, it will generate a list of what would be obliterated, also very useful.
Somehow I get the impression that you should not use a version control system at all. As said before, what you're trying to do goes against everything you would need a version control system for in the first place.
I suggest you create a file system directory structure that makes sense for what you're trying to accomplish and so that you can structure your data. And just make backup's of those files.
TFS has a destroy command that you can use to permanently delete files or revisions as you see fit.
There is more information at this MSDN article.
Many version control systems allow you to configure them in a way so that they store only the differences between several versions of a file and save space through that.
For example if you have a 1Gig file committed, change a part of it and commit it again, only the changed part will be stored in the version control system.
There won't be 2Gigs used (initial and new file) but only 1Gig+sizeOfChanges.
There's just one downside:if you're storing files which change their whole content from revision to revision this can also be counter-productive as the changes take almost the same space as the original version. Archive files are a example for such files where only a small change in the (real) content can lead to a completely changed content of the archive file.
I'd suggest to test several version control systems on your own and with your specific needs and environment and monitor each one at the server-side how the storage requirements for each system changes.
Some distributed version control systems allow to create "checkpoints" that allow you to use this version as kind of a base revision and safe you from pulling all the history before the checkpoint on every checkout. So you can remove the big files, create a checkpoint, and checkout/clone the repository from that checkpoint to a new directory. Then you have there a new, small repository, but without the history before the checkpoint. It you don't need that history you can burn the old repository on CD and use the new, partial one from now on.
I've only tested it in darcs, and there it works, but YMMV depending on version control system and use cases.
It sounds to me like you need an intelligent backup system, rather than version control.
I use SyncBackSE; it allows you to keep a number of previous versions, and can also do things like "ignore all files changed more than 30 days ago".
It's one of the few bits of paid-for software I use. I think it's worth checking out.
I think you're talking about something like "AlienBrain" "bucket" system, aren't you? The ability to remove some revisions from version control.
If you want to destroy an item, it's normally called "obliterate" and it's supported by a number of systems out there.
Buckets, AFAIK are supported by:
AlienBrain
Accurev
PlasticSCM
I would save such files under a unique name (datestamped, perhaps), and perhaps additionally make a textual reference to the external file in the version control system.
Fossil allows you to do this via the "shun" mechanism. Fossil being a distributed SCM, however, means that this does not affect all repositories (for obvious reasons).
My team is working with VSS and we are having difficulties managing versions:
We want to take a "snapshot" of the project we're working on, so we can keep working on it, but when we need to - we can get the files of the snapshot and built them for a release. (Is that called branching?)
Alternatively, getting all project files by date would be great too. (Meaning I would get the last checked-in version of each file in the project prior to the specified date.)
Is there any tutorial regarding this? I searched the net a bit and only found very simple howto's.
Thanks.
As Cannonade wrote, a label might be what you want. But since you explicitly mentioned branching in your question, you should be aware of the differences between a label and a branch:
With a label, you simply mark the current state of all files in your source safe database (the repository). If you created a label "V1.0", you can now at any time easily retrieve exactly that state and rebuild the V1.0 release for example.
With a branch, you create a copy of the current state of your repository. E.g. if you create a copy named "1.0", you can then continue with the development e.g. towards V2.0. Should you ever need to fix a bug for V1.0, then you can do this on the "1.0" branch.
So branches should be used to work on different versions of your projects in parallel. Labels should then be used to mark special versions on your branches (e.g. the ones used to create a release).
One last note: SourceSafe does not have a specific "branch" command. Instead you "Share" your solution and select the option "Branch after share". You can find more information about it in MSDN.
And a very last note: We stopped using SourceSafe about 1.5 years ago and switched to subversion (which is opensource and free). Have a look at subversion or other solutions. I can not imagine ever going back to SourceSafe.
You can apply a label to a current snapshot of source safe (like BUILD1) and then get the tree based on that label at a later date.