Dan Nicholson wrote these words on 02/01/07 19:17 CST: > In my mind, the tag should be static because it marks some sort of > milestone. So, later if I want to find out what's changed since > BLFS-6.2.0rc1 got released, I can do that. There won't suddenly be new > commits there.
That is the plan. In fact, if I would have had my act together, and known there were still so many little nitpicks to fix, there would have only been one commit to the 6.2.0-rc1 tag: a fix to general.ent, the bookinfo and book version files. Nothing even remotely touching actual package instructions. Don't use this 6.2.0-rc1 fiasco as an example of how to go forward. Additionally, please review the email Matthew B. sent about this subject. Not because he agrees with me, but because this issue has been addressed before. > It's fine if this is just going to be a practice milestone or some > other throwaway, but the milestone should stay fixed. It's more about > history than the idea that someone is going to want to actually check > out 6.2.0rc1 in a few months. <Not Arguing, but providing a different perspective>But the tag isn't used for history purposes. The actual SVN repo is used for that. Any changes from SVN release #X to SVN release #Y is easily accomplished using SVN commands. Please don't tell me that someone is going to rely on a tag created 6-18 months apart. That's great for package maintainers (keep in mind my RMLCopyDVD package, where tags actually mean something), but (IMO) worthless in our book world. I think the tag should be used for what is convenient for us, not because someone may say, "hmmmm, I wonder what's been changed since the release candidate, let me manually compare them". And getting back to what you say about "a tag should stay fixed", I think so too, but *after* the tag contains the differences required for the tag to be created in the first place.</Not Arguing> I'm simply not understanding. A tag from SVN is worthless, except as a backup, right? If indeed we want the ability to see what SVN was like some days/months/whatever ago, there are two choices: 1) create a cron job to create a tag once a week. 2) use SVN commands to compare any two versions you wish Now, I can see your point in creating a tag which is exactly some point in time of SVN, and then creating tags from there, but Dan, that is way too much hassle. For example, say you have three release candidates then an actual release. I don't understand how an original point-in-time tag would be of any value. Please explain. And lastly, it appears Archaic, Matthew and I see it one way, with you and Bruce on the other side of the fence. It may just be that I have to make a "command decision" and run with it. Please, don't drop the subject thinking you have no input. I'm learning as we go (as is everyone, I hope), and am willing to be flexible. > As for branching, it just allows the possibility that some changes are > for specific purposes. Not that I'm going to, but now that BLFS-6.2 is > relatively static, I could start checking new stuff back into trunk. > And I wouldn't want that to get mixed up with things needed for 6.2. I don't know how that would work. If we allow trunk to move on with development, then we must selectively merge (just some of) the commits into some tag. And using your method, it couldn't be into the original tag, it would have to be into another. Seems like a bunch of work for nothing. Bottom line is, I think a tag (with just mods to general.ent, the book version file and the bookinfo file; none of which have anything to do with the actual content) fits the need of having a "static" version. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 19:39:00 up 22 days, 19:53, 1 user, load average: 0.56, 0.34, 0.39 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
