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.
On Wed, 10 Aug 2005 00:19:35 +0200, Nitzan Shaked <calius at netvision.net.il> wrote: >I posted here, some 24hrs ago, a script I had just finished writing which >tries to do that. I got a mail back saying my message has to be approved by >a moderator since it was slightly larger than the max 8KB. > >If it does not get posted soon I'll repost. I sincerely hope someone finds >it useful. If it is a script to be used with WinCvs it would probably be useful, but still I would like something like: cvs update -r <special identifier> or similar. What it would do is to reset all files in the sandbox to the first revision existing in the current branch (so if the command was invoked on a non-branched sandbox it would go back to all files at rev 1.1. But of course there is a problem here when I think about it, files that have been added after some work has been done on the branch will have a "first" revision on the branch as well. But we don't want these to remain in the sandbox after running the command so there must be a special case that checks if a file has been added on the branch, in which case it will be purged from the sandbox. This is probably easy to do on a branch but if done on the TRUNK then I guess that there is no way to exclude some files that were added later and therefore carry the revision 1.1? One idea would be to disallow the particular command from running on a sandbox on TRUNK. Or better yet, make it: cvs update -r<branch tag> -s Where the -s option directs cvs to grab the branch start and make it sticky, it is somewhat like cvs update -A to remove stickiness, except it "sticks" the revision on each file at the branch point. The -s option would not be valid unless -r specifies a valid branch tag. What do you think? /Bo (Bo Berglund, developer in Sweden)