What is the best version control system to implement with PowerBuilder 11.5?
If you have examples of how you have did branching/trunk/tags that would be awesome. We have tried to wrap our heads around it a few times and always run into problems because we use shared libraries such as PFC/PFE in multiple applications.
Right now we are only using PBNative, and it sucks.
The Agent SVN is a MS-SCCI Subversion plug-in works with PowerBuilder.
Here is a link that describes how to setup Agent SVN to work with PowerBuilder and Subversion.
We currently use Perforce and it's P4SCC plugin, which works very well. In fact, I'm sure I read somewhere that the guys at Sybase who write PowerBuilder, actually use Perforce themselves.
So, to be fair, let's start out by saying that while you're asking about version control, PBNative is source control. If you compare something that is intended to have more features than just keep two developers from editing the same piece of source, then yes, PBNative will suck. The Madone SL may be an incredible bicycle, but if you're trying to take a couple of laps around an Indy track, it will suck.
"Best" is a pretty subjective word. There are lots of features available in version control and configuration management tools. You can get tons of features, but you'll pay through the nose. StarTeam has some nice features like being able to trace a client change request or bug report all the way through to the changed code, and being able to link in a customized diff tool (which is particularly useful in PB). Then again, if cost is your key criteria rather than features, there are lots of free options that will get the job done. As long as the tool supports the Microsoft SCC interface, you should be OK.
There is a relatively active NNTP newsgroup that focuses on source control with PowerBuilder, which you can also access via the web. You can probably find some already-posted opinions there.
Many years ago I used Starteam to control PB applications. PowerBuilder needless to say is an outdated bear, and it has to export each and every object from its "libraries" into source control.
Currently our legacy PB apps have its libraries saved whole into Subversion, without any support for diff's etc.
We use Visual SourceSafe. We don't use PFC, but we do have libraries that are shared among several projects. Till now, each project was developed separately from the others, and so the shared libraries were duplicated. To have them synchronized, they were all shared at the VSS level. Lately we've reorganized our sources so all projects are near each other, and there's only one instance of the shared libraries.
VSS is definitively not the best source control system, to say the least, but it integrates into PB without the need of any bridges. PB has an inherent problem working with source control, so it probably won't make a very difference working with one instead of the other (at least from the PB point of view).
Now, on a personal note, I'd like to say PB 11.5 is a piece of sh*t. It constantly crashes, full of unbelievable UI nuisance and just brings productivity to its knees. It's probably the worst IDE ever created. Stay away if possible.
FYI: The new PB12 (PB.NET) will integrate with SCC systems so you can easily choose which source control system that you want to use. Since we basically have dropped PBLs (they are now directories) files can be checked in/out individually - even with a plain vanilla editor since files are now normal (unicode) text files.
StarTeam integrates so beautifully with the PB IDE. I used that combination at my previous company (PB9 and ST5.x) for several years. You should be managing your code at the object level - don't log the entire PBL into ST...
If you're having problems with that setup, hit me up offline. phoran at sybase dot com.
We use Merant Version Manager for older projects and TFS for newer work. The only issue we have is that TFS does not support keyword expansion and changing the 'read the flowerbox comments' attitude people have. Some folks are nervous about losing the inline versioning history.
We use StarTeam and have been very pleased with it. It combines bug tracking with version control. Unfortunately though we don't store our files on the object level. We just store the PBL files directly in source control. Anything that supports the SCC interface theoretically should work correctly in PowerBuilder.
PB9: We used PVCS but had stability problems with pbl corruption and also problems co-existing with later versions of Crystal Reports (dll conflict) so now we use PB9 with Dynamsoft's Source Anywhere Standalone. This system is more primitive; it is missing the more advanced features for promotion levels and for pulling out an older milestone version of all objects to make a patch build.
What we are looking for now is something which will allow more advanced "change management", to support promotion levels at the change level (rather than at the object level). Would it be better to use perforce, starteam, or (harvest change manager + HarPB), or something else? Any advice on these combinations would be greatly appreciated.
You can always use Plastic SCM with PowerBuilder through SCC. Plastic is pretty advanced in terms of graphics, tools, replica and so on, so it's always a good choice to keep in mind.
Related
I'm looking for a subversion tool, and i have the following requirements:
Must integrate into VS 2008
Automatically submits new versions
Does not use the command line as primary interface
Doesn't clutter up explorer with bright icon overlays or context menus
is only going to be used by one user mostly if not completely, so doesn't need to have advanced diff tools or anything like that
Basically, i want a subversioning tool that will only bother me when creating a project or actually needing to get something from a previous version.
Does something like that exist, and if so, what is it?
Yes. VisualSVN (commercial)
Except for "automatically submits new versions" - that makes no sense.
The day computers know when your code is ready to be committed and free of bugs is the day the world needs a lot less programmers
You commit when you're done a task, which effectively gives you a rollback point. It's also important to add a meaningful commit message ("Fixed crash when clicking on Save button") - this way you can find things easily later. A lot of new users to version control skip this part, and unfortunately only learn the hard way 3 months later when they need to go back and undo a fix/feature.
AnkhSvn is a free alternative, I've personally only used 1.x, which was really quite terrible. It definitely looks more usable in 2.x.
One upside to VisualSVN is that it uses TortoiseSVN for a lot of its dialogs. This means when you're working with subversion just from explorer, you have basically the same interface and same UI. Quite handy, as it lets you do things like edit images or text files without having to fire up VisualStudio, or edit scripts/installers, or other parts of a product that are not necessarily in VisualStudio.
Yes, they are available.
The two I know of are VisualSVN and AnkhSVN. There are a bunch of comparisons available on SO
I use AnkhSVN myself. It is free, integrates nicely with Visual Studio, and doesn't cause any performance issues.
visual SVN is what you need.
I'm trying to implement a version control system, but as most of us know designers don't feel comfortable with version control systems. I'm looking for a solution mostly for our designers using Photoshop, Flash and other design tools.
It's not a big deal to use a version control system, like VSS 2005, with our frontend and backend coders, but we have some serious problems with our designers. They mostly refuse to use version control systems, and they are right at some points, mostly on productivity level. They mostly work on more than one file, and on more than one application like Photoshop and Flash.
I don't know if version controlling is the right answer or not. Maybe we have to implement a backup system, but there has to be a versioning system, I think. I and our designers are very tired of doing the same thing or going back to the previous designs over and over again.
It would be wonderful to know how digital agencies overcome this problem. If version controlling is the answer, please share your tips on how to make designers comfortable with version controlling.
EDIT 1: Maybe it would be great to have a solution like Dropbox, as it doesn't disturb you with check-ins/check-outs. All you have to do is to open up a file, work on it and save it, the rest is handled by Dropbox.
EDIT 2: We are on Windows, so no chance to implement anything other than Windows support :(
Thanks...
I haven't actually ever done this with graphic designers, but is it possible that Subversion's WebDAV support might work for them? You can mount a WebDAV share as a drive under Mac OS X and Windows XP & Vista, I believe. Each save becomes a new revision in the repository.
And as for your second, hidden question: Yes, you do need to implement a backup system. At least if you value your data.
Adobe has it's own version control, Version Cue, which is bundled with the Creative Suite package. http://www.adobe.com/products/creativesuite/versioncue/sdk_overview/ Apparently, Eclipse can plug into this. I haven't tried it extensively, but I know it integrates nicely into the file dialog in Creative Suite.
NOTE: Version Cue has been discontinued by adobe after the release of CS5:
http://www.adobe.com/products/adobedrive/
Adobe Version Cue maybe?
You might want to try subversion because there are plugins for windows explorer and max OS X finder. integration with the filesystem has been a big help for me on projects where non-developers had to work with source control. This includes projects that have had designers.
Another key thing that helped was having a good directory structure for the files the designers and other non-developers worked with.
I just came accross ConceptShare and it's pretty great...it's not automated version control but you could use it for that and it's a great way to collect and document feedback.
You can try Subversion (installed on a local or remote server) plus Adobe Creative Suite plug-in that would face the designers - Pixelnovel Timeline
It's compact, has previews of all versions (submitted via the plug-in), works for Photoshop, Illustrator & InDesign.
If developers also use Subversion, everything (code & design) can be kept in one place.
Instead of trying to integrate a version control system with lots of applications on different operating systems, you might want to have a look at copy-on-write file systems such as http://en.wikipedia.org/wiki/Ext3cow. That way your designers won't even notice a difference; all they will have to do is save their work to a network share on a linux/samba server using ext3cow.
I'm both a designer and coder. I usually version control code (text data) with git, and simply use "save as" with a version name for graphics (binary data). And I run Apple's Time Machine on top of all that, for safety.
To me, version control on graphic files would just be a burden. I'd have to roll back to see changes, and you wouldn't even get one of the great features of version control: see the changes you did in a specific commit just by looking at diffs. The log feature is nice though, to see how you progressed in time, and notes, but to me personally it's not worth it.
Take a look at Perforce - it has a plugin and tools that allow you to use it from within designer tools such as Photoshop, its also super fast and integrates well with Visual Studio - runs on Windows as well as Linux
What I did once was create a "Snapshot" shortcut on the desktop that added and committed everything from a specific directory.
If every designer commits to their own branch (trivial with a DVCS but easy with SVN too) there will be no conflicts, and the cross-branch merging can be done at intervals by someone who isn't afraid of it.
I've been having my eyes on GridIron's Flow for a while now. It looks like a competent version control suite that has some neat asset management features such as visualization on graphics between versions and relationships between different assets. Flow has support for handling files for adobe photoshop, illustrator, flash etc. However as of now (early january) GridIron hasn't released Flow yet other than having to announce the beta program.
Most digital agencies that I know of that mainly do web development use Subversion for version control. To avoid conflicts on image files an artist will lock the files he or she will work on. That way, another artist won't do the mistake of overwriting changes. This requires some coordination among artists and devs so that noone steps on anyone shoes. Also, if someone forgets to unlock, there is the possibility to break locks.
If you're into distributed version control you might want to take a look at Mercurial as it has good support for Windows and has some neat cheat sheets. The Ruby kids are using git but is rather lacking in Windows.
Before using version control with artists, at least make sure they know the basics of version control and let them fool around with it in a sandbox. Also make sure they've set up some basic rules of conduct when collaborating with each other and interacting through version control (i.e. ways to make sure they don't destroy each others works or step on each others toes).
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system
Our dev shop currently uses Visual SourceSafe. We all know how that could end up (badly), so we're investigating other systems. First up is Perforce. Does anyone have experience with using it and its integration into Visual Studio (2003/2005/2008)? Is it as good as any other, or is it pretty solid with good features, comparatively?
I used Perforce at my last 3 jobs (my current job I'm using Subversion, which I don't like nearly as much.) I'm a big fan of Perforce, and moving from SourceSafe it will seem like Nirvana. Just getting atomic checkin will be a big boost for your company. Otherwise, Perforce is fast, it has good tools, and the workflow is simple for doing things like merges and integrations. I wholeheartedly recommend it. It may not be all new and flashy like the latest distributed VCS's, but honestly, I prefer the client/server model for its speed, especially if you're working with people in other countries that may have slow connections to you.
The Visual Studio integration is pretty good, but it has a few irritating issues. If you run another Perforce client at the same time (like P4V), it's very poor at keeping changes from the other client in sync in terms of showing what files are currently checked in/out. You generally have to shut down Visual Studio and load the project again if you want it to sync correctly. But, the sync status doesn't actually affect checkins/checkouts/updates from working correctly, it just means you can be fooled in to thinking something is in a different state than it actually is while you're in Visual Studio. The Perforce clients will always show the correct status as they sync continually with the database.
Also, on occasion you'll find you need to work "offline" (not connected to the Perforce database for some reason) and when you load the project again the next time, your Perforce bindings may be lost and you'll have to rebind each project individually. If you work with a solution that contains many projects this can be a big pain in the patoot. Same goes for when you first check out a solution, binding to Perforce is needed before the integration occurs.
It's difficult to call $900 per user a good feature.
We used Perforce for well over a year before switching to SVN recently. While I did like the tools (for example, visual diff and merge and the admin bits), we had some really tiresome issues with binding, as Chris mentions; otherwise, the VS integration is satisfactory. If anything, I find working with SVN easier and more intuitive than Perforce. TortoiseSVN (the Windows Explorer shell extension) is great, and we bought a couple of VisualSVN licenses for VS integration. Contrary to Perforce, VisualSVN does not work with the MS SCC interface, but rather directly with the SVN client, which I personally see as an advantage. Perforce does have support for many other OSes, but our non-Windows devs feel more comfortable with SVN too. If I were to have to choose again, I'd stick with SVN.
Sourcegear Vault is the best SCM for migrating VSS users to.
And its cheap.
Perforce works fine with Visual Studio, including "offline" mode where VS will make your local files writable and sync with the server later.
I tend to use the Perforce GUI for many operations (submits, diffs) just because it's quicker/better, but the process of the IDE checking things out is seamless.
Perforce in my experience is rock-solid and the best mixed (code+data) version control product out their if cost is not a factor.
My biggest gripe is that the performance of the server under Windows is no where near as good as under *nix, and if you are using a *nix server they do not officially support the option for case-insensitive filenames (meaning you either forgo support relating to filesystem errors, or setup a trigger that prevents people adding foo.cpp if Foo.cpp exists).
My other main compaint is that for some common operations you have to revert to the command line, often piping functions together. One example would be getting a list of files in a directory that are not under source-control.
Both of these are issues that reflect more on the company than the product though. IMO Perforce know they're at the top of the market and thus see no reason to invest in fixing things like this.
I have experience using a Perforce derivative.
It seemed hard to manage from the admin's perspective, but it was fine to use from a programmer's perspective.
Then again, I'm big on command line version control so can't speak for VS integration.
I've used personally and managed a number of teams for a few years who have been doing Perforce & Visual Studio. It works perfectly well. There can be a couple of binding/rebinding gotchas, but these are generally easy to sort out - Perforce knowledgebase and/or the mailing list is a good source of info.
Never had any problems with using command line, visual clients, and VS IDe simultaneously - refresh normally works fine.
We use perforce extensively in the company, including branching for very large projects, development on Sun Solaris and Windows, and more than 120 users.
It is very fast, and the Windows GUI (P4V) is very nice. The Explorer integration is acceptable. I've disabled the VS integration, and use macros (calling e.g. p4 edit) to edit/revert/diff files. The VS integration is extremely annoying for large projects (our solution has >130 projects), but may work for smaller projects.
I haven't used Perforce, but I have found moving to Team Foundation Server as one of the best options while working with Visual Studio.
Say a development team includes (or makes use of) graphic artists who create all the images that go into a product. Such things include icons, bitmaps, window backgrounds, button images, animations, etc.
Obviously, everything needed to build a piece of software should be under some form of version control. But most version control systems for developers are designed primarily for text-based information. Should the graphics people use the same version-control system and repository that the coders do? If not, what should they use, and what is the best way to keep everything synchronized?
Yes, having art assets in version control is very useful. You get the ability to track history, roll back changes, and you have a single source to do backups with. Keep in mind that art assets are MUCH larger so your server needs to have lots of disk space & network bandwidth.
I've had success with using perforce on very large projects (+100 GB), however we had to wrap access to the version control server with something a little more artist friendly.
I've heard some good things about Alienbrain as well, it does seem to have a very slick UI.
GitHub recently introduced "image view modes", take a look: https://github.com/blog/817-behold-image-view-modes.
We, too, just put the binaries in source control. We use Git, but it would apply just as well to Subversion.
One suggestion I have is to use SVGs where possible, because you can see actual differences. With binaries (most other image formats), the best you can get is a version history.
A lot of the graphics type people will want something more sophisticated than subversion. While it's good for version control, they will want a content management system that allows cross-referencing of assets, tagging, thumbnails and that sort of thing (as well as versioning).
TortoiseSVN can show image revisions side-by-side, which is really useful. I've used it with different teams with a great degree of success. The artists loved having the ability to roll back things (after they got used to the concepts). It does take a lot of space, though.
Interesting question. I don't have a bunch of experience working directly with designers on a project. When I have, it's been through a contractual sort of agreement where they "delivered" a design. I have done some of my own design work for both web sites and desktop applications, and though I have not used source control in the past, I am in the process of implementing SVN for my own use as I am starting to do some paid freelance work. I intend to utilize version/source control precisely the way I would with source code. It just becomes another folder in the project trunk. The way I have worked without source control is to create an assets folder in which all media files that are equivalents of source code reside. I like to think of Photoshop PSD's as graphics source code while the JPEG output for a web site or otherwise is the compiled version.
In the case of working with designers, which is a distinct possibility I face in the near future, I'd like to make an attempt to have them "check-in" their different versions of their source files on a regular basis. I'll be curious to read what others with some experience will say in response to this.
We use subversion. Just place a folder under /trunk/docs for comps and have designers check out and commit to that folder. Works like a champ.
#lomaxx TortoiseSVN includes a program called TortoiseIDiff which looks to be a diff for images. I haven't used it but looks intriguing.
I would definitely put the graphics under version control. The diff might not be very useful from within a diff tool like diffmerge, but you can still checkout two versions of the graphic and view them side by side to see the differences.
I don't see any reason why the resultant graphics shouldn't be kept in the same version control system that the coders use. However, when you're creating graphics using PSD files or PDN files you might want to create a seperate repository for those as they have a different context to the actual end jpeg or gif that is produced and deployed with the developed application.
In my opinion Pixelapse combined with a backup solution is the best version control software for graphics that I've found thus far. It supports adobe files and a bunch of normal raster images. It has version by version preview. It autosaves when the files update(on save). It works like dropbox but have a great web interface.
You can use it in teams and share projects to different people. It also support infinite reviewers which is great for design agencies. And if you want you can publicly collaborate on projects that are "open".
Unfortunately you can't have a local pixelapse server, so for backup my current setup is that I have the Pixelapse folder(like a dropbox folder) inside a git repo for snapshot creation.
With respect to diff and merging, I think the version control is more critical for graphics and media elements. If you think about it, most designers are going to be the sole owners of a file -- at least in the case of graphics -- or at least I would think that'd be the case. I'd be curious to hear from a designer.
#Damian - Good point about the tagging and cross referencing. That's true; while I haven't working with many designers on a software development project, I have worked for a company that had a design department and know that this is an issue. Designers are still (perpetually) looking for the perfect system to handle this sort of thing. I think this is more suited to a design department for shared access, searching and versioning, etc to all assets -- where there is a business incentive to not reinvent the wheel wherever/whenever possible. I don't think it would apply for a project-oriented manner as tagging and cross referencing wouldn't be quite as applicable.
We keep the binary files and images in revision control, using Perforce. It's great!
We keep a lot of art assets, and it scales well for lots of large files. It recognizes binary files, the ones that can't be diffed, and stores them as full file copies in the back end.
It has P4V (cross-platform visual browser), and a thumbnail system so image files can be seen in the browser.
You might want to take a look at Boar: "Simple version control and backup for photos, videos and other binary files". It can handle binary files of any size. http://code.google.com/p/boar/
A free and slightly wonky solution is Adobe version Cue its comes with the Adobe Suites up to CS4 and is easy to install and maintain. Offers user level control and is artist friendly. Adobe has discontinued support though for it which is a shame. Adobe Bridge acts as the client between the user and the Version Cue server. If used properly its an inexpensive solution to version control. I use CS3 version cue with CS3 Bridge. Works great for small teams.