Jeff Newmiller wrote: > > On Wed, 10 Jul 2002, Michael D. Schleif wrote:
[ snip ] > > [1] Should I have separate trees for different underlying versions of > > net-snmp? For example, I committed net-snmp v4.2.4. I am contemplating > > building and committing both v4.2.5 and the totally different > > distribution v5.x. So, one line of thinking is like this: > > > > devel/helices/net-snmp/v4.2.4/netsnmp.lrp ... > > devel/helices/net-snmp/v4.2.5/netsnmp.lrp ... > > devel/helices/net-snmp/v5.0.2/netsnmp.lrp ... > > This seems quite the wrong direction. CVS is supposed to manage > versioning completely independently of the directory structure. Yes, I agree. However, I am dealing with somebody else's software and making it suitable for leaf. Obviously, I can have several iterations of net-snmp v4.2.4 that address various leaf concerns. Also, I must be prepared for somebody else's version upgrades causing problems that do not exist in previous versions. For most part, net-snmp v4.2.5 fixes a number of things a small number of people found problematic in v4.2.4. However, v4.2.5 also created problems for a small number of users that did not exist in v4.2.4. So, in reality, my package has two (2) versioning systems running in parallel: somebody else's and leaf/mine. How can cvs facilitate this distinction? > > [2] Perhaps, my net-snmp package, for instance, should be in cvs in > > expanded form, so that when only one (1) or a few file contents change, > > that will be directly reflected in cvs? Under this scenario, when only > > a single file -- perhaps, the primary binary? -- is changed, users can > > checkout only that file. > > This sounds good. I am new to cvs; so, bear with me. Under this scenario, committing to cvs directory structures, cvs is responsible for knowing whether or not a specific file or directory has changed? Any change, including mod/grp/own? What happens when I decide that /usr/sbin/ntp_setup actually belongs /usr/bin/ntp_setup? Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp? Clearly, cvs cannot know my intent, in this regard. When committing a directory change, under this scenario, how should it be done? > > [3] Item [2] presents a difficulty when a user wants the whole LRP > > package as one (1) LRP file. Is there some way to properly archive and > > compress a cvs directory tree and check that out? > > If possible, but probably not. Probably should use both expanded and > packaged form. Yes, I like this, too. > > [4] I am still confused on how best to handle package descriptions. > > <http://leaf.sourceforge.net/devel/helices/net-snmp/> presents several > > TXT files that, once clicked on, present descriptive text regarding the > > LRP's that reside in versioned directories below this one. Another > > example is Jacques Nilo's <http://leaf.sourceforge.net/devel/jnilo/> > > wonderful page that links to installation and troubleshooting > > information. How are we to do this under cvs? > > After presenting two approaches you use the pronoun "this"?? I am sorry; but, I lumped these two together to make a generic documentation point. During commit, I am presented with an editor session, in which I am allowed to enter text. I wonder whether or not this allowance should rather be a requirement? What is it that this commit blurb is intended to convey? Is this intended to be an introduction to the package? A simple statement of my/leaf or somebody else's version upgraded to whatever? What should I, joe-leaf-user, expect to find while perusing ViewCVS? > CVS is designed to handle directories full of information... so a > directory tree of html documents is a natural thing to enter. > > An idea... > > net-snmp/ > README.txt > package/ > net-snmp.lrp > target/ > etc/ > blahblah > usr/ > bin/ > snmpbinary > ... > doc/ > index.html > images/ > image1.jpg > ... > src/ > sourcefiles... > > Let CVS deal with versioning. I rather like this structure. It is intuitive to navigate, complex enough to deal with complex packages, and simple enough to maintain. I worry, however, if every developer goes about creating some adhoc structure to their liking . . . OK, yes, it is time to stop worrying about whatever shenanigans some other might do ;> > David Douthitt has advocated (and it sounds good to me but I haven't done > it myself) a mechanism whereby sources obtained from other sources are > kept in original form and a parallel directory containing patchfiles and > compilation instructions is generated to allow LEAF-specific modifications > to be maintained separate from the original source tree if > necessary. Read the archives... :) I've been looking at what others have done and when I looked at David's, I saw a directory structure that didn't mean anything to me and could not find any files, other than Makefile. What am I missing? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
