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.
Johan, What you are talking about sounds similar to what some developers and I were discussing yesterday which I would like to suggest to March-Hare as a possible feature for CVSNT 2.6 or 2.7. The concept is what Team System call a "Shelf", and the way it was explained to me is something like this and it makes a truck load of sense to me. * A developer checks out a repository into a sandbox. * Makes changes and the code is not ready to be committed, but for backup purposes the developer can "commit" the changes to the "shelf". It is stored in CVS, can be viewed in CVS but if someone else checks out the module or project those changes are NOT included. The developer can rollback to a previous "shelf" version if they want and can commit more changes to the shelf. * At some point the "shelf" is committed as a normal committ. The other advantage to this is the shelf can be used as a "review" check point. A developer commits his/her changes to the shelf and another developer or manager reviews the changes there before approving the changes to be committed to the main repository. If a developer with shelf changes does a update, they would still get all changes committed to the repository. Any clashes with "shelf" copies would be merged in a normal fashion. I guess rethinking this it is like a mini/temporary branch but without the overhead of creating and managing branches. Using your example, a tester checks out the test plans and makes changes to one. Anyone else checking out does not get the changes made by the tester. At some point the testers test plan changes are approved to go into the repository and move from the shelf to the repository. Just some thoughts. Trevor -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Johan Holmberg Sent: Thursday, 23 February 2006 12:55 p.m. To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: [cvsnt] Re: "cvs update" avoiding files with local changes? Gerhard Fiedler <lists at connectionbrazil.com> writes: > Johan Holmberg wrote: > > > I should perhaps have explained my situation in more detail. My > > scenario (in this case) is to use "cvs update" in a "batch setting" > > to update all files in a whole directory tree. The files are *self > > contained*, so the usual dependency problems don't arise. When there > > is un-committed local changes, it is for a good reason. The most > > important thing (in batch mode) is to *avoid* overwriting these > > changes, not even with a successful merge. I want those changes to > > be managed interactively later. [...] > > I have thought about switching to some "mirroring software". It > > would probably fit nicely with the "batch mode". But then I would > > loose the nice things with CVS when working in "interactive mode": > > using diff, accessing file history, commiting changes, etc. > > I don't quite understand this, especially how a mirroring software > would come into play. As I wrote in my previous message, in situations > that may be similar to yours (I don't really understand your work flow > yet), [...] Concerning the workflow: I develop a "test engine" used by 20 compiler developers. The system has around 10_000 testcases. Normally the developers get the files via the test engine without even having to know that the testcases are stored in CVS (what I called "batch mode" earlier). Occasionally a developer is forced to make local changes to a testcase. These changes are used locally for a while, and later considered for addition to the central CVS archive. In the meantime it is important that the developer can get other changes from the server (like "cvs update" would do). But the locally changed files should be left alone (if they happens to be changed on the server too). So the usage is 98% "batch mode" (the developer doesn't care about CVS). But in the other 2% of cases CVS comes in very handy. I have a homegrown mirroring solution that can solve the "batch mode" for me, but if we used it, we would be forced to handle the 2% in a different (and worse) way. Returning to my original question: my current understanding and conclusion is that no variant of "update" exists, that avoid updating conflicting files. Maybe I should hack the CVS source :-) /Johan Holmberg _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs ###################################################################### Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. ######################################################################