Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

Ugh, I just reverted to the prior enforce script. I'll take a look at it
again in the morning.

Currently lowercase name enforcement is active.


On Tue, 2002-07-16 at 17:12, Mike Noyes wrote:
> Everyone,
> I just removed the lowercase enforcement from our repository. If win
> clients start leaving broken stub files in our repository, we'll need to
> reexamine this issue.
> 
> 
> On Thu, 2002-07-11 at 16:59, Mike Noyes wrote:
> > On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote:
> > > You should not force all filenames (except Makefile) to lowercase.
> > > Some kernel modules have uppercase letters in their names.
> > > Also the README files are typically in uppercase.
> > > An X terminal dist would have big problems with that rule.
> > 
> > I believe this was done to address the following problem:
> > Introduction to SourceForge.net Project CVS Services
> > https://sourceforge.net/docman/display_doc.php?docid=768&group_id=1
> > Case Sensitivity
> > When a developer performs certain types of CVS operations,
> > specifically "cvs add" and "cvs remove", CVS checks the listing
> > of already-deleted files for that directory (i.e. the files in
> > the Attic for that directory) to see if there is a match of the
> > same filename. There is a difference between what MS
> > Windows-based systems consider a match and what case-sensitive
> > operating systems, such as Linux (which is used to provide the
> > project CVS services), see as a match in these cases. If the
> > filename match does not occur on the server, but there would be
> > a case-insensitive match, the Windows-based CVS client will
> > abort its operation and leave a broken stub file within the
> > repository, which must be removed by SourceForge.net staff.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

Everyone,
I just removed the lowercase enforcement from our repository. If win
clients start leaving broken stub files in our repository, we'll need to
reexamine this issue.


On Thu, 2002-07-11 at 16:59, Mike Noyes wrote:
> On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote:
> > You should not force all filenames (except Makefile) to lowercase.
> > Some kernel modules have uppercase letters in their names.
> > Also the README files are typically in uppercase.
> > An X terminal dist would have big problems with that rule.
> 
> I believe this was done to address the following problem:
> Introduction to SourceForge.net Project CVS Services
> https://sourceforge.net/docman/display_doc.php?docid=768&group_id=1
> Case Sensitivity
> When a developer performs certain types of CVS operations,
> specifically "cvs add" and "cvs remove", CVS checks the listing
> of already-deleted files for that directory (i.e. the files in
> the Attic for that directory) to see if there is a match of the
> same filename. There is a difference between what MS
> Windows-based systems consider a match and what case-sensitive
> operating systems, such as Linux (which is used to provide the
> project CVS services), see as a match in these cases. If the
> filename match does not occur on the server, but there would be
> a case-insensitive match, the Windows-based CVS client will
> abort its operation and leave a broken stub file within the
> repository, which must be removed by SourceForge.net staff.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote:
> I had a quick look at the enforce scripts.

Manfred,
Thanks for taking a look. :-)
Note: the enforce scripts were written by Jacob Moorman, and copied from
the sitedocs cvsroot. I modified the directory and permissions files for
our repository.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sitedocs/CVSROOT/

> You should not force all filenames (except Makefile) to lowercase.
> Some kernel modules have uppercase letters in their names.
> Also the README files are typically in uppercase.
> An X terminal dist would have big problems with that rule.

I believe this was done to address the following problem:
Introduction to SourceForge.net Project CVS Services
https://sourceforge.net/docman/display_doc.php?docid=768&group_id=1
Case Sensitivity
When a developer performs certain types of CVS operations,
specifically "cvs add" and "cvs remove", CVS checks the listing
of already-deleted files for that directory (i.e. the files in
the Attic for that directory) to see if there is a match of the
same filename. There is a difference between what MS
Windows-based systems consider a match and what case-sensitive
operating systems, such as Linux (which is used to provide the
project CVS services), see as a match in these cases. If the
filename match does not occur on the server, but there would be
a case-insensitive match, the Windows-based CVS client will
abort its operation and leave a broken stub file within the
repository, which must be removed by SourceForge.net staff.


> Attic should not be allowed as name.

This sounds like a good idea. I'll try to talk with Jacob about it
tomorrow.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Manfred Schuler]

Mike Noyes schrieb:
> 
> On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote:
> > Mike Noyes schrieb:
> > > On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> > > > Manfred,
> > > > I looked at this example again, and I think the sequence below is an
> > > > accepatble solution for it.
> > >
> > > Here is a small but significant addition to this sequence. It will allow
> > > retrieval of the tree in its 1.0 state.
> > >
> > > 1$ cvs -q tag R_1_0
> > > 2$ cp scriptb scriptc
> > > 3$ cvs add scriptc
> > > 4$ cvs ci -m "added scriptc old filename was scriptb" scriptc
> > > 5$ rm scriptb
> > > 6$ cvs remove scriptb
> > > 7$ cvs ci -m "removed scriptb new filename is scriptc" scriptb
> >
> > [snip]
> >
> > I recommend to tag every release with an appropriate label.
> > So you can retrieve any old release or verify what is released.
> > I also recommend to tag the latest release with somthing like 'latest'
> > for easy retrieval.
> 
> Manfred,
> Agreed. Tags are good. :-)
> 
> > I don't think this sequence will work because in line 5 you remove
> > scriptb
> > and in line 7 you try to checkin scriptb.
> 
> I believe this sequence is correct, and a checkin is required to move
> the file to the Attic in the repository.
> 
> ref.
> http://cvsbook.red-bean.com/cvsbook.html#Removing_Files
> http://cvsbook.red-bean.com/cvsbook.html#What_Happens_When_You_Remove_A_File
> 
You are right. 
I was irritated by 'ci' (check in). 'commit' would make things easier to
understand.
Checking in a nonexisting file looks strange.

> > I have no experience with cvs and from the man pages I could not
> > determine
> > if line 6 removes only the last version or all versions of scriptb.
> > If it removes all versions you get the problem with version 0.9.
> >
> > I would use this sequence
> >
> > cvs -q tag R_1_0
> > cvs -f ci -m "file renamed to scriptc" scriptb
> 
> >From the cvs man page:
>  commit  [-lnR]  [-m 'log_message' | -f file] [-r revision] [files...]
> Sometimes  you may want to force a file to be  committed  even
> though  it  is unchanged; this is achieved with the -f flag, which
> also has the effect of disabling recursion (you can turn it back on
> with -R of course).
> 
> How will this help?
The intention was to get a final log message.
You get it when you commit the remove.
> 
> > cvs -q tag -d MAIN scriptb
> > mv scriptb scriptc
> > cvs add scriptc
> > cvs ci -m "file renamed from scriptb" scriptc
> >
> > This sequence is not tested. It is just what I can read from
> > the man pages. Maybe you need additonally this line
> > cvs remove scriptb
> > but as mentioned, I don't know what exactly is removed.
> > Maybe the tag MAIN cannot be deleted, although I couldn't find
> > it in the man page.
> 

I had a quick look at the enforce scripts.

You should not force all filenames (except Makefile) to lowercase.
Some kernel modules have uppercase letters in their names.
Also the README files are typically in uppercase.
An X terminal dist would have big problems with that rule.

Attic should not be allowed as name.

-- 
Manfred Schuler
E_Mail: mailto:[EMAIL PROTECTED]


---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote:
> Mike Noyes schrieb:
> > On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> > > Manfred,
> > > I looked at this example again, and I think the sequence below is an
> > > accepatble solution for it.
> > 
> > Here is a small but significant addition to this sequence. It will allow
> > retrieval of the tree in its 1.0 state.
> > 
> > 1$ cvs -q tag R_1_0
> > 2$ cp scriptb scriptc
> > 3$ cvs add scriptc
> > 4$ cvs ci -m "added scriptc old filename was scriptb" scriptc
> > 5$ rm scriptb
> > 6$ cvs remove scriptb
> > 7$ cvs ci -m "removed scriptb new filename is scriptc" scriptb
> 
> [snip]
> 
> I recommend to tag every release with an appropriate label.
> So you can retrieve any old release or verify what is released.
> I also recommend to tag the latest release with somthing like 'latest'
> for easy retrieval.

Manfred,
Agreed. Tags are good. :-)

> I don't think this sequence will work because in line 5 you remove
> scriptb
> and in line 7 you try to checkin scriptb.

I believe this sequence is correct, and a checkin is required to move
the file to the Attic in the repository.

ref.
http://cvsbook.red-bean.com/cvsbook.html#Removing_Files
http://cvsbook.red-bean.com/cvsbook.html#What_Happens_When_You_Remove_A_File

> I have no experience with cvs and from the man pages I could not
> determine
> if line 6 removes only the last version or all versions of scriptb.
> If it removes all versions you get the problem with version 0.9.
> 
> I would use this sequence
> 
> cvs -q tag R_1_0
> cvs -f ci -m "file renamed to scriptc" scriptb

>From the cvs man page:
 commit  [-lnR]  [-m 'log_message' | -f file] [-r revision] [files...]
Sometimes  you may want to force a file to be  committed  even 
though  it  is unchanged; this is achieved with the -f flag, which
also has the effect of disabling recursion (you can turn it back on
with -R of course).

How will this help?

> cvs -q tag -d MAIN scriptb
> mv scriptb scriptc
> cvs add scriptc
> cvs ci -m "file renamed from scriptb" scriptc
> 
> This sequence is not tested. It is just what I can read from
> the man pages. Maybe you need additonally this line
> cvs remove scriptb
> but as mentioned, I don't know what exactly is removed.
> Maybe the tag MAIN cannot be deleted, although I couldn't find
> it in the man page.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Manfred Schuler]

Mike Noyes schrieb:
> 
> On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> > Manfred,
> > I looked at this example again, and I think the sequence below is an
> > accepatble solution for it.
> 
> Here is a small but significant addition to this sequence. It will allow
> retrieval of the tree in its 1.0 state.
> 
> 1$ cvs -q tag R_1_0
> 2$ cp scriptb scriptc
> 3$ cvs add scriptc
> 4$ cvs ci -m "added scriptc old filename was scriptb" scriptc
> 5$ rm scriptb
> 6$ cvs remove scriptb
> 7$ cvs ci -m "removed scriptb new filename is scriptc" scriptb

[snip]

I recommend to tag every release with an appropriate label.
So you can retrieve any old release or verify what is released.
I also recommend to tag the latest release with somthing like 'latest'
for easy retrieval.

I don't think this sequence will work because in line 5 you remove
scriptb
and in line 7 you try to checkin scriptb.

I have no experience with cvs and from the man pages I could not
determine
if line 6 removes only the last version or all versions of scriptb.
If it removes all versions you get the problem with version 0.9.

I would use this sequence

cvs -q tag R_1_0
cvs -f ci -m "file renamed to scriptc" scriptb
cvs -q tag -d MAIN scriptb
mv scriptb scriptc
cvs add scriptc
cvs ci -m "file renamed from scriptb" scriptc

This sequence is not tested. It is just what I can read from
the man pages. Maybe you need additonally this line
cvs remove scriptb
but as mentioned, I don't know what exactly is removed.
Maybe the tag MAIN cannot be deleted, although I couldn't find
it in the man page.

-- 
Manfred Schuler
E_Mail: mailto:[EMAIL PROTECTED]


---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Thu, 2002-07-11 at 13:17, Manfred Schuler wrote:
> Comments inline

Manfred,
Thanks for the analysis. I'm glad I don't appear to be causing problems
in our repository.

> Mike Noyes schrieb:
> > [ 547717 ] CVS repository clean-up: leaf
> > 
>https://sourceforge.net/tracker/index.php?func=detail&aid=547717&group_id=1&atid=21
> Removing 'x' bit should do no harm

I added some enforce scripts to our CVSROOT recently. Would you take a
look at them and let me know if you see any problems? Thanks.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/CVSROOT/

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Manfred Schuler]

Comments inline

Mike Noyes schrieb:
> 
> On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> > It is meant as a principle when working on large projects:
> >   _NEVER_ change anything that is correctly checked in
> 
> Manfred,
> Incorrectly checked in files/directories are candidates for SF staff cvs
> repository clean-up support requests (SR). I believe there are other
> instances where SF cvs SRs are appropriate too. Please take a look at
> our old SF SRs. In which cases should I have used standard cvs commands
> to accomplish these tasks?
> 
> [ 574291 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=574291&group_id=1&atid=21
removing empty directories or renaming a top level directory should not
impose any problem
because there should not be any dependencies.
> 
> [ 547717 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=547717&group_id=1&atid=21
Removing 'x' bit should do no harm
> 
> [ 547118 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=547118&group_id=1&atid=21
> 
Removing 'x' bit should do no harm
> [ 525177 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=525177&group_id=1&atid=21
> 
top level directory, ok
> [ #513309 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=513309&group_id=1&atid=21
> 
top level directory, ok
> [ #503058 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=503058&group_id=1&atid=21
> 
Developers top level directory, should be ok
> --
> Mike Noyes <[EMAIL PROTECTED]>
> http://sourceforge.net/users/mhnoyes/
> http://leaf-project.org/
> 
> ---
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> 
> ___
> Leaf-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

-- 
Manfred Schuler
E_Mail: mailto:[EMAIL PROTECTED]


---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Manfred Schuler]

Mike Noyes schrieb:
> 
> On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> > Mike,
> >
> > I did _NOT_ at all want to criticize the staff at SF.
> > I know about them only what I see on the list, so I'm
> > not in a position to judge how they do their job.
> 
> Manfred,
> I apologize for the tone of my last message. It was inappropriate.
> Sorry.
> 

No reason to apologize.

> > I think I didn't express clearly what I mean.
> >
> > It is meant as a principle when working on large projects:
> >   _NEVER_ change anything that is correctly checked in
> >
> > I will give you an example of what I mean:
> >
> > In version 1.0 of package xxx you have 2 script files:
> > scripta and scriptb
> > One line in scripta is
> >   source scriptb
> >
> > Later you decide scriptb is not a good name and you change the name
> > to scriptc and the line in scripta to:
> >   source scriptc
> > The version 1.1 of the package xxx consists now of the files
> > scripta and scriptc.
> > Now you rename scriptb in your CVS tree to scriptc.
> >
> > A user who wants to checkout version 1.0 gets a problem because
> > scripta requires scriptb, but someone who dosen't know about
> > the rename, doesn't know where to get scriptb.
> >
> > Even when the label is moved with the files, you get
> > scripta and scriptc on checkout, but the package won't work
> > because of the wrong filename.
> >
> > You see, when you rename files in CVS, you get nonfunctional old
> > versions.
> 
> Ah, now I see. :-)
> I hadn't considered this sequence of actions. I believe interdependent
> files that require movement/renaming are candidates for branches. Would
> branching the sample above be an appropriate course of action?
> 

No need to branch. Just remove the HEAD and MAIN tags from the old file.

-- 
Manfred Schuler
E_Mail: mailto:[EMAIL PROTECTED]


---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> It is meant as a principle when working on large projects:
>   _NEVER_ change anything that is correctly checked in

Manfred,
Incorrectly checked in files/directories are candidates for SF staff cvs
repository clean-up support requests (SR). I believe there are other
instances where SF cvs SRs are appropriate too. Please take a look at
our old SF SRs. In which cases should I have used standard cvs commands
to accomplish these tasks?

[ 574291 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=574291&group_id=1&atid=21

[ 547717 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=547717&group_id=1&atid=21

[ 547118 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=547118&group_id=1&atid=21

[ 525177 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=525177&group_id=1&atid=21

[ #513309 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=513309&group_id=1&atid=21

[ #503058 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=503058&group_id=1&atid=21

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> Manfred,
> I looked at this example again, and I think the sequence below is an
> accepatble solution for it.

Here is a small but significant addition to this sequence. It will allow
retrieval of the tree in its 1.0 state.

$ cvs -q tag R_1_0
> $ cp scriptb scriptc
> $ cvs add scriptc
> $ cvs ci -m "added scriptc old filename was scriptb" scriptc
> $ rm scriptb
> $ cvs remove scriptb
> $ cvs ci -m "removed scriptb new filename is scriptc" scriptb
> 
> I believe this will leave the repository in a correct state, and solve
> the older version retrieval problem.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> I think I didn't express clearly what I mean.
> 
> It is meant as a principle when working on large projects:
>   _NEVER_ change anything that is correctly checked in
> 
> I will give you an example of what I mean:
> 
> In version 1.0 of package xxx you have 2 script files:
> scripta and scriptb
> One line in scripta is
>   source scriptb
> 
> Later you decide scriptb is not a good name and you change the name
> to scriptc and the line in scripta to:
>   source scriptc
> The version 1.1 of the package xxx consists now of the files
> scripta and scriptc.
> Now you rename scriptb in your CVS tree to scriptc.

Manfred,
I looked at this example again, and I think the sequence below is an
accepatble solution for it.

$ cp scriptb scriptc
$ cvs add scriptc
$ cvs ci -m "added scriptc old filename was scriptb" scriptc
$ rm scriptb
$ cvs remove scriptb
$ cvs ci -m "removed scriptb new filename is scriptc" scriptb

I believe this will leave the repository in a correct state, and solve
the older version retrieval problem.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> Mike,
> 
> I did _NOT_ at all want to criticize the staff at SF.
> I know about them only what I see on the list, so I'm
> not in a position to judge how they do their job.

Manfred,
I apologize for the tone of my last message. It was inappropriate.
Sorry.

> I think I didn't express clearly what I mean.
> 
> It is meant as a principle when working on large projects:
>   _NEVER_ change anything that is correctly checked in
> 
> I will give you an example of what I mean:
> 
> In version 1.0 of package xxx you have 2 script files:
> scripta and scriptb
> One line in scripta is
>   source scriptb
> 
> Later you decide scriptb is not a good name and you change the name
> to scriptc and the line in scripta to:
>   source scriptc
> The version 1.1 of the package xxx consists now of the files
> scripta and scriptc.
> Now you rename scriptb in your CVS tree to scriptc.
> 
> A user who wants to checkout version 1.0 gets a problem because
> scripta requires scriptb, but someone who dosen't know about
> the rename, doesn't know where to get scriptb.
> 
> Even when the label is moved with the files, you get 
> scripta and scriptc on checkout, but the package won't work
> because of the wrong filename.
> 
> You see, when you rename files in CVS, you get nonfunctional old
> versions.

Ah, now I see. :-)
I hadn't considered this sequence of actions. I believe interdependent
files that require movement/renaming are candidates for branches. Would
branching the sample above be an appropriate course of action? 

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Manfred Schuler]

Mike,

I did _NOT_ at all want to criticize the staff at SF.
I know about them only what I see on the list, so I'm
not in a position to judge how they do their job.

I think I didn't express clearly what I mean.

It is meant as a principle when working on large projects:
_NEVER_ change anything that is correctly checked in

I will give you an example of what I mean:

In version 1.0 of package xxx you have 2 script files:
scripta and scriptb
One line in scripta is
source scriptb

Later you decide scriptb is not a good name and you change the name
to scriptc and the line in scripta to:
source scriptc
The version 1.1 of the package xxx consists now of the files
scripta and scriptc.
Now you rename scriptb in your CVS tree to scriptc.

A user who wants to checkout version 1.0 gets a problem because
scripta requires scriptb, but someone who dosen't know about
the rename, doesn't know where to get scriptb.

Even when the label is moved with the files, you get 
scripta and scriptc on checkout, but the package won't work
because of the wrong filename.

You see, when you rename files in CVS, you get nonfunctional old
versions.

Mike Noyes schrieb:
> 
> On Thu, 2002-07-11 at 03:56, Manfred Schuler wrote:
> > Mike Noyes schrieb:
> > > If we had shell access to the repository, we would hand edit the
> > > structure change. SF doesn't allow us shell access to the cvs server, so
> > > we need to open SF support requests to make changes like this.
> > >
> > > ref. CVS repository clean-up requests
> > > https://sourceforge.net/tracker/?group_id=1&atid=21
> >
> > I don't think it is a good idea to make a change like this.
> > If someone wants to retrieve an older version, it does not work
> > because the file he needs is not available anymore.
> > It is better to create the new file in CVS and pin the
> > release/version tag to the new file and not to the old file.
> 
> Manfred,
> That has not been my experience. When the SF staff moves/renames files
> on the SF cvs server they maintain the cvs structure. Talk with Jacob
> Moorman, Quality of Service Manager ('moorman' on SourceForge.net,
> 'moorman' on SlashNET IRC) to verify this if you like.
> 
> --
> Mike Noyes <[EMAIL PROTECTED]>
> http://sourceforge.net/users/mhnoyes/
> http://leaf-project.org/
> 
> ---
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> 
> ___
> Leaf-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

-- 
Manfred Schuler
E_Mail: mailto:[EMAIL PROTECTED]


---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Thu, 2002-07-11 at 03:56, Manfred Schuler wrote:
> Mike Noyes schrieb:
> > If we had shell access to the repository, we would hand edit the
> > structure change. SF doesn't allow us shell access to the cvs server, so
> > we need to open SF support requests to make changes like this.
> > 
> > ref. CVS repository clean-up requests
> > https://sourceforge.net/tracker/?group_id=1&atid=21
> 
> I don't think it is a good idea to make a change like this.
> If someone wants to retrieve an older version, it does not work
> because the file he needs is not available anymore.
> It is better to create the new file in CVS and pin the 
> release/version tag to the new file and not to the old file.

Manfred,
That has not been my experience. When the SF staff moves/renames files
on the SF cvs server they maintain the cvs structure. Talk with Jacob
Moorman, Quality of Service Manager ('moorman' on SourceForge.net,
'moorman' on SlashNET IRC) to verify this if you like.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Manfred Schuler]

Mike Noyes schrieb:

[snip]

> > 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?
> 
> If we had shell access to the repository, we would hand edit the
> structure change. SF doesn't allow us shell access to the cvs server, so
> we need to open SF support requests to make changes like this.
> 
> ref. CVS repository clean-up requests
> https://sourceforge.net/tracker/?group_id=1&atid=21
> 

I don't think it is a good idea to make a change like this.
If someone wants to retrieve an older version, it does not work
because the file he needs is not available anymore.
It is better to create the new file in CVS and pin the 
release/version tag to the new file and not to the old file.

[snip]

-- 
Manfred Schuler
E_Mail: mailto:[EMAIL PROTECTED]


---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[guitarlynn]

On Wednesday 10 July 2002 19:41, Michael D. Schleif wrote:

> Yes, these are our (leaf) _cvs_ versions.  However, how can a user
> select net-snmp v4.2.4 when my net-snmp version is 1.1?

Well, the editor session that pops up during a commit can be avoided
with the -m "text" switch added to the commit command... I use for
notes based on the change(s) from earlier CVS versions of the same
package. You can use this to differeniate between net-snmp v4.2.4, 
4.2.5, and 5.0.1 (not to mention any other notables you would like
to add). As I am working on doing, if you would like certain versions
of the same CVS file(s) presented in a clear and special manner, simply
link them from a web page that presents this information. 

> > > What should I, joe-leaf-user, expect to find while perusing
> > > ViewCVS?
> >

Joe-User is usually looking for an exact package in CVS rather than
aimlessly attempting to find something random. I think most major
software groups use CVS from linked web pages as well.


> Right now, I'm only thinking about what goes under my devel/helices
> tree.  How that gets tied into dcd, bering, or whatever, is another
> issue, which I've decided to ignore for the moment.  Remember, this
> all started with your request to me to commit my net-snmp packages. 
> I committed the LRP's only, and since I've begun to plan committing
> several other items.  It's this planning that has me hung now; but,
> I'd really like to put that behind me ;>

I think you are doing the smartest thing by planning you tree. A good
plan will save tons of time and effort at a later date by foreseeable
circumstances.
-- 

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!


---
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

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Wed, 2002-07-10 at 17:41, Michael D. Schleif wrote:
> 
> Mike Noyes wrote:
> > 
> > On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> > CVS retains all previous versions of a file in the repository. You can
> > specify a specific version for retrieval.
> > 
> > Example:
> > 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp
> > 
> > Download version 1.10
> > 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEAD&content-type=application/octet-stream
> > 
> > Download version 1.1
> > 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1&content-type=application/octet-stream
> 
> Yes, these are our (leaf) _cvs_ versions.  However, how can a user
> select net-snmp v4.2.4 when my net-snmp version is 1.1?

Michael,
A simple href on a web page will work. Lynn is already doing this on his
pages.

net-snmp.lrp v4.2.4

http://leaf-project.org/devel/guitarlynn/

> > > 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?
> > 
> > If we had shell access to the repository, we would hand edit the
> > structure change. SF doesn't allow us shell access to the cvs server, so
> > we need to open SF support requests to make changes like this.
> 
> If this is all that is available to us -- and, really, such requests
> seem to be available to only a few, like you, Mike -- then, it behooves
> me to select a good structure now, before I have to request alot of
> changes.  That is why I belabor this point now.

I understand your concerns, but the SF staff are happy to make any
changes we may need (move, rename, remove). You can talk with them on
irc if you want to verify this(irc.slashnet.org channel #sourceforge).
BTW, I'm there most of the day too.

Note: changes of this type take from 24 to 72 hours of working days to
process. A project admin usually needs to make the requested change.

Note 2: I keep a log of all SF support requests that are opened for our
project in this task.
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=45595&group_id=13751&group_project_id=5257

Note 3: If you have a problem with one of the SF services please add a
comment to this task.
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=45594&group_id=13751&group_project_id=5257

> > > What should I, joe-leaf-user, expect to find while perusing ViewCVS?
> > 
> > doc -- released documentation
> > bin/packages -- released packages sorted by library type/revision
> > 
> > binary files for LEAF release/branch tree (write access controlled
> > by lead developer)
> > /bering
> > /dachstein
> > /oxygen
> > /packetfilter
> > /wisp-dist
> > /wrp
> > src -- source code
> 
> Is that like Jeff's earlier directory structure outline, or is this
> referring to the text to include in the cvs commit blurb?

This is the current LEAF repository structure. see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/


> > Think of the devel tree as individual repositories, and the doc, bin,
> > and src trees as community resources. Did that help?
> 
> Right now, I'm only thinking about what goes under my devel/helices
> tree.  How that gets tied into dcd, bering, or whatever, is another
> issue, which I've decided to ignore for the moment.  Remember, this all
> started with your request to me to commit my net-snmp packages.  I
> committed the LRP's only, and since I've begun to plan committing
> several other items.  It's this planning that has me hung now; but, I'd
> really like to put that behind me ;>

Understood. I'm not sure how I can assist you with this though, as each
developer has different ideas of what a repository should look like.
Maybe these links will help.

CVS Documentation
http://www.cvshome.org/docs/

# Open Source Development with CVS by Karl Fogel
http://cvsbook.red-bean.com/cvsbook.html

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
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

Re: [Leaf-devel] CVS structure ??? [LONG]

[Michael D. Schleif]

Mike Noyes wrote:
> 
> On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> >
> > Jeff Newmiller wrote:
> > >
> > > On Wed, 10 Jul 2002, Michael D. Schleif wrote:
> >
> > > > [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.
> 
> Michael,
> CVS retains all previous versions of a file in the repository. You can
> specify a specific version for retrieval.
> 
> Example:
> 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp
> 
> Download version 1.10
> 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEAD&content-type=application/octet-stream
> 
> Download version 1.1
> 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1&content-type=application/octet-stream

Yes, these are our (leaf) _cvs_ versions.  However, how can a user
select net-snmp v4.2.4 when my net-snmp version is 1.1?

> > 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?
> 
> If we had shell access to the repository, we would hand edit the
> structure change. SF doesn't allow us shell access to the cvs server, so
> we need to open SF support requests to make changes like this.

If this is all that is available to us -- and, really, such requests
seem to be available to only a few, like you, Mike -- then, it behooves
me to select a good structure now, before I have to request alot of
changes.  That is why I belabor this point now.

[ snip ]

> > What should I, joe-leaf-user, expect to find while perusing ViewCVS?
> 
> doc -- released documentation
> bin/packages -- released packages sorted by library type/revision
> 
> binary files for LEAF release/branch tree (write access controlled
> by lead developer)
> /bering
> /dachstein
> /oxygen
> /packetfilter
> /wisp-dist
> /wrp
> src -- source code

Is that like Jeff's earlier directory structure outline, or is this
referring to the text to include in the cvs commit blurb?

> > I worry, however, if every developer goes about creating some adhoc
> > structure to their liking . . .
> 
> Think of the devel tree as individual repositories, and the doc, bin,
> and src trees as community resources. Did that help?

Right now, I'm only thinking about what goes under my devel/helices
tree.  How that gets tied into dcd, bering, or whatever, is another
issue, which I've decided to ignore for the moment.  Remember, this all
started with your request to me to commit my net-snmp packages.  I
committed the LRP's only, and since I've begun to plan committing
several other items.  It's this planning that has me hung now; but, I'd
really like to put that behind me ;>

-- 

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

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> 
> 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.

Michael,
CVS retains all previous versions of a file in the repository. You can
specify a specific version for retrieval.

Example:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp

Download version 1.10
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEAD&content-type=application/octet-stream

Download version 1.1
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1&content-type=application/octet-stream


> 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?

If we had shell access to the repository, we would hand edit the
structure change. SF doesn't allow us shell access to the cvs server, so
we need to open SF support requests to make changes like this.

ref. CVS repository clean-up requests
https://sourceforge.net/tracker/?group_id=1&atid=21


> 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?

doc -- released documentation
bin/packages -- released packages sorted by library type/revision

binary files for LEAF release/branch tree (write access controlled
by lead developer)
/bering
/dachstein
/oxygen
/packetfilter
/wisp-dist
/wrp
src -- source code 


> I worry, however, if every developer goes about creating some adhoc
> structure to their liking . . .

Think of the devel tree as individual repositories, and the doc, bin,
and src trees as community resources. Did that help?

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
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

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Wed, 2002-07-10 at 15:39, Charles Steinkuehler wrote:
> > 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?
> 
> CVS doesn't track file permissions or ownership...just contents.

Charles,
CVS does track the x bit of committed files. The x bit is set on import
and add commands.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
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

Re: [Leaf-devel] CVS structure ??? [LONG]

[Charles Steinkuehler]

> 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?

See "Open source development with CVS" by Karl Fogel (Coriolis
press...also, parts are available online).  The last part of chapter 6
has a section on using vendor branches to track 3rd party software.
This basically describes how to import an external code-base into a
local CVS tree, using CVS to track any local changes, and finally how to
import a new release, if/when it becomes available from the 3rd party
(ie the NetSnmp folks).

> 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?

CVS doesn't track file permissions or ownership...just contents.

> 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?

Moving files once they're in CVS is ugly...see the above reference for
details.  There's a CVS replacement in the works that tries to clean up
a bunch of CVS's rough edges, but it's not in widespread use yet.

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



---
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

Re: [Leaf-devel] CVS structure ??? [LONG]

[Michael D. Schleif]

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.
> >  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 
> > 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?

-- 

Bes