Re: address@hidden: Re: [Jeff Bailey <address@hidden>] Re: [Savannah-hackers] savannah.gnu.org: submission of GNU and FSF Organizational Files]

[Hugo Gayosso]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


[ Added some cc: because of the scope of the message, and because I am
not the only behind this idea.]


"Leonard H. Tower Jr." <address@hidden> writes:

>    From: Hugo Gayosso <address@hidden>
>    Date: 31 Mar 2001 00:56:34 -0500
> 
> 
>    This is what I do:
> 
>    I do a `cvs checkout' (from command line).
> 
>    C-x C-f to read the file.
>    Edit the file to my pleasure.
>    C-x v v (Initiates the commit)
>    Type the log message (in the new Emacs window that opened).
>    C-c C-c (commits the file and the log message)
> 
>    I don't care if the file is under RCS, under local CVS or under remote
>    CVS.
> 
>    When you checkout a copy via CVS there is a directory called "CVS"
>    take a look inside it and you will find 3 files that contains all the
>    necessary information to find the repository (local or remote).
> 
> Hugh:

I am Hugo, not Hugh ;) (but no offense taken)



> The ``cvs checkout' (from command line)'' is NOT inside GNU Emacs.

I know that's why I specified it.


> It's also substantially more complicated then the local case.

Ok, I don't get your point, so I have to ask: "So ?" I mean, what is
the problem if the remote case is more difficult than the local case,
they are completely independent.


> In the local case, all you need to know how to do is deal with a vc
> mode command or two.  

Nope, in the local case (future local case I mean, not currently) we
establish the "public working copy" and all they have to do is SAVE
the file, the checkin and update will be done automatically, or at
least that would be the idea.



> In the remote case, you need this local case knowledge, PLUS the deep
> magic of how to do a CVS checkout, what exists to checkout, where to
> check it out, etc.  A lot more learning curve.  A lot more to teach.

You lost me here, if the user doesn't want to learn CVS, then he/she
goes to the "public working copy" and edit the files, just as they are
now. He/she doesn't have to think about checkouts and checkins.

The remote case is only for people that know how to use CVS and find
it convenient.



> The remote case makes it much harder to browse, and learn.  
>
> In the remote case, each user has to commit an large amount of disk
> space to maintain his checkouted copy.

I am talking only about gnuorg, not www. Besides www is ALREADY under
CVS, there were different announcements from loic.


> The remote case is best seen as an optimization for certain kinds of
> users who have to deal with bad net connectivity, NOT as a total
> replacement for the local case.


Any takers on this?


>    In the case of the "public working copy" that I mentioned, the working
>    copy ALWAYS stays there, so the first step (cvs checkout) is a
>    one-time event.
> 
> This is a good idea in the gnuorg case.  (It remains a poor idea in
> the www.gnu.org case).  Especially if it's on the same machine and
> it's location documented in a README file in the tree.

I am talking only about gnuorg, but as I said before, WWW is ALREADY
under CVS only.


> It essentially reduces the problem to the local case, plus some cron
> jobs.  Ideally, the GNU Emacs vc mode checkin would also update the
> remote CVS master (you would still want the sync cron jobs to guard
> against use of other editors and CVS wizards who forget steps).
>
> I know understand what should be done in the /gd/gnuorg case, and will
> let all the addresses know in a few days when I have time again.
> 
>            address@hidden@gnu.org
> 
> I did not mis-spell any addresses.  I mistyped a "," as a ".".
> and I had forgotten that I resent the message. 
> 
> If my RSI'ed wrists had been hurting less, I would have mentioned the
> mis-typed "," in the resend.
> 
> Apologies.

No problem.

Greetings,
- -- 
Hugo Gayosso
Support the Free Software
Support the GNU Project 
http://www.gnu.org
http://wildebeest.penguinpowered.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6xYgpMNObVRBZveYRArKQAJ0Z4Kj7liaXo/ijHrDN+pRUkCbUyQCeMv7M
GOLGxSVXI4xirqiw1YCW968=
=H0eR
-----END PGP SIGNATURE-----