(I should have combined this with my previous response - sorry for the extra message). I think the inconsistency arises because $Name$ is the only keyword that can change value when fetching from the
Well "cvs up -kk -j <branch-tag-1> -j <branch-tag-2>" seems to work okay for me to avoid problems with merging the keywords (I think we've only used $Id$, though). -- Jamie Wellnitz
I agree - consistent date format is good, and using an ISO standard is even better. I think the RCSkeywords should also be expanded. Now, having said that, I also have to point out that I'm not awar
Is it third-party source, or is it your source tree and you're only using import for convenience? If it's your source tree, you could move the binaries out of the way, do the import, check out a sand
If most user will be in single timezone, it is natural that format of date is in the timezone. For example, Japanese teritory is smal, there is one timezone. Commercial user in non-global company des
Sorry to hear that Patrick. Indeed, Subversion implements the same behavior as the proposed patch. Subversion allows keywords properties to be specified to a file. Changes to keyword data are not eve
Method #1, I think if the update is done with the '-kk' option it will stop the expansion. Method #2, tell your developers to stop using keywords and remove them where ever they find them. Method #3
Thanks to all for comments and suggestions! I'm not challenging your opinion, I'm trying to understand how the thing works. I would be glad if you could elaborate one level deeper and answer the ques
We have just moved our repository and my commitinfo script has stopped working. I am not sure why. I am getting a directory name followed by a list of files as parameters to my script. It then tries
[ On Friday, September 14, 2001 at 18:39:58 (-0700), Paul Sander wrote: ] Well, I've certainly not ignored them. Whenever I've come across them I've pointed out that CVS is not the right tool to use
How do I switch a file checked in (whether on purpose or inadvertently) from binary to plain text? I found this discussion, but it doesn't seem to be working as expected: http://groups.google.com/gro
Ignored? Not entirely. The closest you can come is to add the -kk flag to the command: cvs update -kk -j... -j... After you have resolved your conflicts, use cvs update -kkv to restore the default va
Thankx Mark But, I think Probably its advisable not to switch off the Keyword Substitution. Would howsoever may affect the RCS files . Till Next Regards Gurpreet S $Name:<text>$ is one of the RCS key
Um. I mean that I've read the manual, but my developers, whose only purpose is to sit and code Java more slowly than I could COBOL (note that I don't *know* COBOL), who I have using CVS because it sa
[ On Saturday, April 13, 2002 at 16:15:13 (-0400), gabriel rosenkoetter wrote: ] What, exactly, do you mean by "as long as you remember"!?!?!?! You're using CVS, are you not? Did you not RTFM? You'd
If you're going this route, I would suggest your commitinfo script also check for the existence of RCSkeywords within the files. I think such enforcement would require too much overhead. Also, even
Only if there are RCSkeywords in the file that also change as a result of the checkin. Like I said, using RCSkeywords to get under-the-table changes made on the server back to the client is a kludg
Heh. So I'm not so off-track. This is basically what I have ended up doing, and have recommended to others... Let's say the project/contract is FOO. The branches are 'bar' and 'baz', with my primary
The problem with using local time in CVS, either in history reports, or in keywords, is that it's mostly a problem in the mind of the person reading the time. Anyone who has experience in any domain