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.
Victor A. Wagner Jr. wrote: > Although I can think of no real reason to tag the entire repository, it > seems to me that in addition to taking a fair amount of time, it's going > to add a fair amount of space to the repository. > > It seems to me that the effect people would be looking for is to restore > some sandbox to the state of the entire repository at some unlikely time > in the future (or are there people who keep only _one_ project per > repository?). well, our repository contains ~50 .dlls that make up a single windows program, yes..... Plus a few odd extra projects here and there, but the bulk of it is a single project > Since all a tag does is create a synonym (in _each_ file (the space part > of the spacetime mentioned in the subject)) for some (generally the > current) revision, it's clear that any process that's going to "mark" > each file will take significant time. > > I suspect that administrators would really prefer a way to mark the > repository as it is "right now". > > That being the case, why not simply record the date/time with the "name" > you want to give to the 'tag' someplace, and timestamp it. Last I > checked, one could do checkouts and updates using a datetime as an > argument. Yes it would be a two step process to "get" all the relevant > files from the repository, but the "tagging" would take the time of > doing a commit on a single file (if you put your "tag name" in the file > before committing it. > > Alternatively, in case you're _really, really_ in love with tags, you > could force some file to commit (using the -f option) then rtag _it_. > I'd suggest using one of the files that exists in the CVSROOT if you're > going to do such a stunt (it likely is changeable only by admins already). > > surely it would be rather easy to put together a small script that will > do either the "tagging" or the two steps necessary to update/checkout. The only problem here is that when a dev is using viewcvs to see what version of file A is in version X, or to see the differences between version X and version Y he won't see the information he needs.... This would all work OK if using the command line, but we aren't. I suppose I *could* mod viewcvs, but..... thanks, -kz