Moving CVS files around?
I'm considering moving s_lock.c from backend/storage/buffer, where it
seems to make no sense, into backend/storage/lmgr which seems like a
more logical place for it. However, the only way to do it that I know
of is to "cvs remove" in the one directory and then "cvs add" a new copy
in the other. That would lose the CVS log history of the file, or at
least make it a lot harder to find. Is there a way to attach the past
commit history to the file in its new location? Should I just do it and
not worry about the history? Should I leave well enough alone?
regards, tom lane
I'm considering moving s_lock.c from backend/storage/buffer, where it
seems to make no sense, into backend/storage/lmgr which seems like a
more logical place for it. However, the only way to do it that I know
of is to "cvs remove" in the one directory and then "cvs add" a new copy
in the other. That would lose the CVS log history of the file, or at
least make it a lot harder to find. Is there a way to attach the past
commit history to the file in its new location? Should I just do it and
not worry about the history? Should I leave well enough alone?
I vote you just move it. It never made sense in /buffer to me either.
I always looked for it in lmgr first.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
When moving files in CVS I usually use the cvs add/cvs remove in the same
commit with -m something like 'Changed location/name for file xxx to yyy'.
That way you have trace in the log about what happened to a file as both
old/new name/location.
Maybe not the nicest way but it usually works fine and I haven't found a
better way yet.
IMHO you should just do it and not worry about the history. If someone wants
to read it they will have to issue a few more commands and as time
progresses there are usually less and less interest in the old history. It's
better than start fiddling around with CVS-files.
/Stefan
Tom Lane wrote:
Show quoted text
I'm considering moving s_lock.c from backend/storage/buffer, where it
seems to make no sense, into backend/storage/lmgr which seems like a
more logical place for it. However, the only way to do it that I know
of is to "cvs remove" in the one directory and then "cvs add" a new copy
in the other. That would lose the CVS log history of the file, or at
least make it a lot harder to find. Is there a way to attach the past
commit history to the file in its new location? Should I just do it and
not worry about the history? Should I leave well enough alone?regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
I can move it manually on the backend ... let me know when/if you want it
done ...
On Mon, 1 Oct 2001, Stefan Rindeskar wrote:
Show quoted text
When moving files in CVS I usually use the cvs add/cvs remove in the same
commit with -m something like 'Changed location/name for file xxx to yyy'.That way you have trace in the log about what happened to a file as both
old/new name/location.Maybe not the nicest way but it usually works fine and I haven't found a
better way yet.IMHO you should just do it and not worry about the history. If someone wants
to read it they will have to issue a few more commands and as time
progresses there are usually less and less interest in the old history. It's
better than start fiddling around with CVS-files./Stefan
Tom Lane wrote:
I'm considering moving s_lock.c from backend/storage/buffer, where it
seems to make no sense, into backend/storage/lmgr which seems like a
more logical place for it. However, the only way to do it that I know
of is to "cvs remove" in the one directory and then "cvs add" a new copy
in the other. That would lose the CVS log history of the file, or at
least make it a lot harder to find. Is there a way to attach the past
commit history to the file in its new location? Should I just do it and
not worry about the history? Should I leave well enough alone?regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster