Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> In CVS, a "project" tends to be defined by a directory tree. > The files in that directory tree are either in the CVS > project or they are in no project at all. If you have > administrator privileges, I believe there are some tricks you > can play with overlapping modules, but the average user is > left out in the cold. You do not have to be an admin to define modules and they're not rocket science either. Only 3 of your "advantages" could not easily be accomplished using modules definitions as well: 1. There is indeed no GUI, at least none that I'm aware of - certainly no built-in one. It's perfectly doable though and I've actually already got something in the back of my mind. The only thing that's missing is time... ;) 2. Modules could not sensibly be versioned. I see this as their biggest and only real-life disadvantage against your alternative. 3. A module definition does indeed only ever work from a root directory upwards, i.e. you could not (sensibly) manage files in various scattered locations within a single module. So far I haven't met a real-life scenario where this would have been necessary. Of course YMMV. > * You can have a project that includes files in multiple > directory trees. > > * You can have multiple projects in a single directory tree > or even in a single directory. > > * Since projects are composed of files AND are defined by > files, you have easily have a master project composed of > files AND other [sub]projects. Those subproject can likewise > have subprojects and so on. As a result, you can deal with > you application as a single Source Integrity [master] > project, or you can deal with the individual components of > your application, or right on down to a project that is a > single executable. These are all perfectly doable using modules definitions. > Another feature I liked about Source Integrity was their > equivalent of the CVS Update command. In CVS, it seems that > you have to accept Update on blind faith. It will update > your source tree with changes made in the repository, but it > will also automatically merge your changes with those made by > others (surprise, surprise). That's kind of the point of doing an update, isn't it? > In Source Integrity, when you > launch the GUI (or when you request comparison with the > repository) files are tagged with icons indicating who has > been changed. You can then request to see those changes, > accept those change into your source tree, or keep your > source tree as it is. Nothing happens behind your back. Nothing happens "behind your back" in CVS either. There are methods aplenty to query for remote changes before update, it's just following an on-demand model rather than a push model. This is also the main reason why CVS works so well over the internet. Personally, I don't /want/ to know what's going on in the repository any earlier than I *really* want to know... Cheers, Oliver ------ In everybody's best interest, please do not post or CC technical questions to me in private unless they are specifically about a macro/product of mine that is NOT already bundled with WinCvs. I will generally forward my replies to such posts to the CVSGUI list without further notice. ---- ------------------ JID: ogiesen at jabber.org ICQ: 18777742 (http://wwp.icq.com/18777742)