Re: [Patches] [Patch #101055] Cookie.py
[Overquoting for the sake of python-dev readers] On Fri, Aug 18, 2000 at 04:06:20PM -0400, Fred L. Drake, Jr. wrote:
amk writes:
I have a copy of Tim O'Malley's Cookie.py,v file (in order to preserve the version history). I can either ask the SF admins to drop it into the right place in the CVS repository, but will that screw up the Python 1.6 tagging in some way? (I would expect not, but who knows?)
That would have no effect on any of the Python tagging. It's probably worthwhile making sure there are no tags in the ,v file, but that can be done after it gets dropped in place. Now, Greg Stein will tell us that dropping this into place is the wrong thing to do. What it *will* screw up is people asking for the state of Python at a specific date before the file was actually added; they'll get this file even for when it wasn't in the Python CVS tree. I can live with that, but we should make a policy decision for the Python tree regarding this sort of thing.
Excellent point. GvR's probably the only person whose ruling matters on this point; I'll try to remember it and bring it up whenever he gets back (next week, right?).
Don't -- it's not worth it.
I hate throwing away information that stands even a tiny chance of being useful; good thing the price of disk storage keeps dropping, eh? The version history might contain details that will be useful in future debugging or code comprehension, so I dislike losing it forever. (My minimalist side is saying that the enhanced Web tools should be a separately downloadable package. But you probably guessed that already...) --amk
On Fri, Aug 18, 2000 at 04:48:37PM -0400, Andrew Kuchling wrote: [ About adding Cookie.py including CVS history ]
I hate throwing away information that stands even a tiny chance of being useful; good thing the price of disk storage keeps dropping, eh? The version history might contain details that will be useful in future debugging or code comprehension, so I dislike losing it forever.
It would be moderately nice to have the versioning info, though I think Fred has a point when he says that it might be confusing for people: it would look like the file had been in the CVS repository the whole time, and it would be very hard to see where the file had been added to Python. And what about new versions ? Would this file be adopted by Python, would changes by the original author be incorporated ? How about version history for those changes ? The way it usually goes (as far as my experience goes) is that such files are updated only periodically. Would those updates incorporate the history of those changes as well ? Unless Cookie.py is really split off, and we're going to maintain a separate version, I don't think it's worth worrying about the version history as such. Pointing to the 'main' version and it's history should be enough. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters <thomas@xs4all.net> writes: TW> It would be moderately nice to have the versioning info, TW> though I think Fred has a point when he says that it might be TW> confusing for people: it would look like the file had been in TW> the CVS repository the whole time, and it would be very hard TW> to see where the file had been added to Python.
I don't think that's true, because the file won't have the tag information in it. That could be a problem in and of itself, but I dunno. -Barry
Barry A. Warsaw writes:
I don't think that's true, because the file won't have the tag information in it. That could be a problem in and of itself, but I dunno.
The confusion isn't from the tags, but the dates; if the ,v was created 2 years ago, asking for the python tree as of a year ago (using -D <date>) will include the file, even though it wasn't part of our repository then. Asking for a specific tag (using -r <tag>) will properly not include it unless there's a matching tag there. -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
"AK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes:
AK> I hate throwing away information that stands even a tiny AK> chance of being useful; good thing the price of disk storage AK> keeps dropping, eh? The version history might contain details AK> that will be useful in future debugging or code comprehension, AK> so I dislike losing it forever. I agree. Let's try to keep the revision history for Cookie.py. -Barry
participants (4)
-
Andrew Kuchling -
bwarsaw＠beopen.com -
Fred L. Drake, Jr. -
Thomas Wouters