Two weeks ago;
ext/pcre/config0.m4
was added by duplicating ext/pcre/config.m4,v directly in the CVS repository.
Unfortunately this breaks every historical checkout, due to the now duplicate
existance of config0.m4 and config.m4, causing duplicate builds of the pcre
extention.
Of course, if one wants to do this in order to preserve history, it's still
essential to remove all prior tags from the new ,v file - to avoid exactly
this sort of duplicate checkout -by tag-. Of course checkouts by date would
still check out duplicate files.
And of course nobody wants the true history concealed by removing the old,
now removed file from Attic/. So the patch to the true config0.m4,v is
attached for someone to modify this directly in cvs. Note this is specific
to today's untagged state, and within days this patch would become invalid
when config0.m4,v is tagged with new, non- config.m4,v tags.
Bill
Not that we will patch the repository files, but why do you care?
You actually use some old release branch? :)
--Jani
Two weeks ago;
ext/pcre/config0.m4
was added by duplicating ext/pcre/config.m4,v directly in the CVS repository.
Unfortunately this breaks every historical checkout, due to the now duplicate
existance of config0.m4 and config.m4, causing duplicate builds of the pcre
extention.Of course, if one wants to do this in order to preserve history, it's still
essential to remove all prior tags from the new ,v file - to avoid exactly
this sort of duplicate checkout -by tag-. Of course checkouts by date would
still check out duplicate files.And of course nobody wants the true history concealed by removing the old,
now removed file from Attic/. So the patch to the true config0.m4,v is
attached for someone to modify this directly in cvs. Note this is specific
to today's untagged state, and within days this patch would become invalid
when config0.m4,v is tagged with new, non- config.m4,v tags.Bill
Jani Taskinen wrote:
Not that we will patch the repository files, but why do you care? You actually use some old release branch? :)
I think that we should try to preserve the possiblity to checkout an old
version of PHP directly from the CVS.
Edin
Jani Taskinen wrote:
Not that we will patch the repository files, but why do you care? You actually use some old release branch? :)I think that we should try to preserve the possiblity to checkout an old
version of PHP directly from the CVS.
It's a bit late to say that now..we've moved lot more files around than
just this one. Or have we? (good memory, just short :)
If you're comfortable patching the file, feel free. I don't care as long
as it won't break HEAD or PHP_5_1 branches.
--Jani
Hello Jani,
the solution is correct. And btw just another reason to switch to svn.
Without the patch the old branches magically inherit the new file just as
we could change the past.
best regards
marcus
Wednesday, December 7, 2005, 11:13:10 AM, you wrote:
Jani Taskinen wrote:
Not that we will patch the repository files, but why do you care? You actually use some old release branch? :)I think that we should try to preserve the possiblity to checkout an old
version of PHP directly from the CVS.
It's a bit late to say that now..we've moved lot more files around than just this one. Or have we? (good memory, just short :)
If you're comfortable patching the file, feel free. I don't care as long as it won't break HEAD or PHP_5_1 branches.
--Jani
Best regards,
Marcus
Marcus Boerger wrote:
the solution is correct. And btw just another reason to switch to svn.
Without the patch the old branches magically inherit the new file just as
we could change the past.
I have applied the patch. SVN has its own set of problems.
-Rasmus
Rasmus Lerdorf wrote:
Marcus Boerger wrote:
the solution is correct. And btw just another reason to switch to svn.
Without the patch the old branches magically inherit the new file just as
we could change the past.I have applied the patch.
Thanks Rasmus, and Marcus for your analysis.
SVN has its own set of problems.
Especially with respect to importing your CVS history - these various tweaks
to CVS can burn the importer, it will be quite a chore to indentify those
subtly corrupt ,v files, tweak them, and ensure the resulting repository is
golden.
However SVN has one distinct advantage, and that's when you are reorganizing.
Renaming files -and directories- is painless, and history is preserved. Not
that I'm advocating either way.
Bill
Jani Taskinen wrote:
Not that we will patch the repository files, but why do you care? You actually use some old release branch? :)
In case I wasn't clear, or the patch wasn't clear, this is -every- historical
checkout that's broken. Including those in the past month.
If you're comfortable patching the file, feel free. I don't care as long
as it won't break HEAD or PHP_5_1 branches.
ROFL - now that's funny!
Bill