You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Martin Kraemer <Ma...@mch.sni.de> on 1998/02/02 22:05:40 UTC
Re: cvs commit: apache-1.3/src/ap Makefile.tmpl
Ken wrote,
> Log:
> Phase 2 of moving the .h files into src/include.. modify the scripts
> and Makefiles that reference them.
You actually did MOVE the CVS files from one directory into the other?
(Or why didn't the apache-cvs list receive the appropriate delete/add
messages)? That's usually not the way to go because this way your're
"faking history". For someone who tries to get the apache tree of,
say, Jan 01 1998, he'll now be unable to compile (because the files are no
longer in the directories where they were back then).
Therefore, the safest procedure, history-wise, is to
mv ap/xxxx.h ap/yyy.h include/
cvs rm ap/xxxx.h ap/yyy.h
cvs add include/xxxx.h include/yyy.h
cvs ci ap/xxxx.h ap/yyy.h include/xxxx.h include/yyy.h
This way, there's no "time warp", and the files in include/ are
created only for time stamps from the beginning of their existance
in that directory (not their "previous lives" as ap/*.h).
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: cvs commit: apache-1.3/src/ap Makefile.tmpl
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Martin Kraemer wrote:
>
> You actually did MOVE the CVS files from one directory into the other?
Yes, I did.
> That's usually not the way to go because this way your're
> "faking history".
I don't see it as faking the history at all. The history is about changes
made to the contents of the file, not the metainformation about where
it's located. But that's just my opinion of the moment.
> For someone who tries to get the apache tree of,
> say, Jan 01 1998, he'll now be unable to compile (because the files are no
> longer in the directories where they were back then).
That's a valid point that I hadn't considered.
> Therefore, the safest procedure, history-wise, is to
>
> mv ap/xxxx.h ap/yyy.h include/
> cvs rm ap/xxxx.h ap/yyy.h
> cvs add include/xxxx.h include/yyy.h
> cvs ci ap/xxxx.h ap/yyy.h include/xxxx.h include/yyy.h
>
> This way, there's no "time warp", and the files in include/ are
> created only for time stamps from the beginning of their existance
> in that directory (not their "previous lives" as ap/*.h).
But you lose all the history about why changes were made to the file
- which I was trying to avoid.
#ken P-)}
Re: cvs commit: apache-1.3/src/ap Makefile.tmpl
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Mon, Feb 02, 1998 at 06:04:42PM -0500, Rodent of Unusual Size wrote:
> Excuse me? It seems to me that this is something that could be done
> even now (if it's done quickly, before changes start getting made to
> the .h files). Just cp the ,v files from include back to their
> original homes, and then cvs rm them.
Yup. Should work.
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: cvs commit: apache-1.3/src/ap Makefile.tmpl
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Martin Kraemer wrote:
>
> On Mon, Feb 02, 1998 at 02:14:24PM -0700, Marc Slemko wrote:
> > The better solution could be to cp the ,v files, then CVS rm them from
> > where they used to be so they are still in Attic.
> I thought of that as well; but that would populate include/ even before
> its very existence.
Excuse me? It seems to me that this is something that could be done
even now (if it's done quickly, before changes start getting made to
the .h files). Just cp the ,v files from include back to their
original homes, and then cvs rm them.
#ken P-)}
Re: cvs commit: apache-1.3/src/ap Makefile.tmpl
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 2 Feb 1998, Martin Kraemer wrote:
> On Mon, Feb 02, 1998 at 02:14:24PM -0700, Marc Slemko wrote:
> > The problem with that is that you loose the history. I don't like that.
> > It is bad.
>
> No, you don't (it's still in the old dir's Attic/). But you lose the
> possibility to compare include/1p.h as of today with ap/ap.h as of one week
> ago.
You lose the history in the file; going to hunt somewhere for it isn't the
same...
>
> > The better solution could be to cp the ,v files, then CVS rm them from
> > where they used to be so they are still in Attic.
> I thought of that as well; but that would populate include/ even before
> its very existence.
Tough.
CVS does not allow you to move files, period. Any way you do it you will
screw up. Having a few extra files around in old trees is better than the
other alternatives. It does not break things.
I really don't see any option... yea, we could move to perforce which I
think handles it and we can get free server and client, but... I don't
like that.
Re: cvs commit: apache-1.3/src/ap Makefile.tmpl
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Mon, Feb 02, 1998 at 02:14:24PM -0700, Marc Slemko wrote:
> The problem with that is that you loose the history. I don't like that.
> It is bad.
No, you don't (it's still in the old dir's Attic/). But you lose the
possibility to compare include/1p.h as of today with ap/ap.h as of one week
ago.
> The better solution could be to cp the ,v files, then CVS rm them from
> where they used to be so they are still in Attic.
I thought of that as well; but that would populate include/ even before
its very existence.
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: cvs commit: apache-1.3/src/ap Makefile.tmpl
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 2 Feb 1998, Martin Kraemer wrote:
> Ken wrote,
> > Log:
> > Phase 2 of moving the .h files into src/include.. modify the scripts
> > and Makefiles that reference them.
>
> You actually did MOVE the CVS files from one directory into the other?
> (Or why didn't the apache-cvs list receive the appropriate delete/add
> messages)? That's usually not the way to go because this way your're
> "faking history". For someone who tries to get the apache tree of,
> say, Jan 01 1998, he'll now be unable to compile (because the files are no
> longer in the directories where they were back then).
>
> Therefore, the safest procedure, history-wise, is to
>
> mv ap/xxxx.h ap/yyy.h include/
> cvs rm ap/xxxx.h ap/yyy.h
> cvs add include/xxxx.h include/yyy.h
> cvs ci ap/xxxx.h ap/yyy.h include/xxxx.h include/yyy.h
>
> This way, there's no "time warp", and the files in include/ are
> created only for time stamps from the beginning of their existance
> in that directory (not their "previous lives" as ap/*.h).
The problem with that is that you loose the history. I don't like that.
It is bad.
The better solution could be to cp the ,v files, then CVS rm them from
where they used to be so they are still in Attic.
>
> Martin
> --
> | S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
> | ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
> | N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
> ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
>