Thread: 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, Pennsylvania19026
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? > > http://www.postgresql.org/users-lounge/docs/faq.html
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: > 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? > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >