> >> Eric Sandeen <sandeen@xxxxxxx> writes:
>
> > I'm not sure what the advantage would be? It's no more stable right
> > after a kernel merge, or anything like that. But if you convince me
> > that it's useful, I could probably do it. No promises though, I just
> > got a whole lot more(!) busy as of last week.
>
> I sympathize. The point is to make it easier to compare the XFS tree
> with the kernel tree, that is, to be able to check out the version
> right after a given merge at any point in time. I'm asking this
> because yesterday I was merging current XFS CVS with 2.4.5 and there
> were a couple of points where I was left wondering when and why a
> change was made, and I wished I could have the status of the CVS tree
> right after 2.4.4 was merged. I ended up figuring out the dates for
> the merge, but using tags is easier...
One thing you do not know is that this cvs tree is recreated from scratch
every hour, from a different tree which uses a different (still rcs) based
internal tree. The reason for this is that the internal tree includes
revisions of the files prior to the open source release of XFS, and
therefore potentially has code which the legal people insist we do not
allow outside the company. However, we internally need to keep the old
revisions and source code mechanism to match up with yet other trees
within SGI.
Because of this, adding tags to the cvs tree actually means adding tags to
the other tree, and that may be harder than adding a cvs tag to the files.
Steve
|