#4 should support :local: and :ext: CVSROOT

Next_Release
open
None
7
2004-07-26
2002-12-02
No

this was easy enough to add support for (hacked in) -
be good if it worked out of the box.

Great project, BTW! Thanks!

Discussion

  • Adam Kennedy

    Adam Kennedy - 2002-12-03
    • assigned_to: nobody --> adamkennedy
    • priority: 5 --> 3
     
  • Adam Kennedy

    Adam Kennedy - 2002-12-03

    Logged In: YES
    user_id=153576

    There are some problems with local repositories ( you mean
    CVSROOT=/var/cvs style right? ) because of local file
    permissions. Often the web user does not have permissions
    to the CVS root on the local filesystem.

    I'm afraid I'm not familiar with :ext: repositories...

    Feel free to enlighten me, or add a patch.

     
  • Adam Kennedy

    Adam Kennedy - 2002-12-03
    • assigned_to: adamkennedy --> nobody
    • labels: 474215 -->
     
  • Adam Kennedy

    Adam Kennedy - 2002-12-03

    Logged In: YES
    user_id=153576

    Moving to feature request

     
  • Jonathan Hedley

    Jonathan Hedley - 2002-12-04

    Logged In: YES
    user_id=661742

    I think it would be good if one could force the repository,
    without the tests.

    Some systems might not allow the webserver read access to
    a local repository, but that shouldn't lock it out for those
    which can.

    :ext: looks at the environment CVS_RSH, and allows access
    to a repository by rsh or ssh (perhaps others aswell?). I
    modified cvsmonitor.pl to set up the environment (you could
    put this in the apache startup I suppose), and had
    CVSMonitor::MetaData::Repository return the :ext: repository
    without tests, and it works fine.

    Eg:

    $ENV{'CVS_RSH'} = 'ssh';
    return ':ext:username@cvs.server:/cvs/repository/';

    Obviously the web sever user needs to have an ssh identity
    and authorized key set up.

     
  • Adam Kennedy

    Adam Kennedy - 2002-12-04

    Logged In: YES
    user_id=153576

    OK, that doesn't look like to much of a big change.

    Is there any way to check whether the ssh identity stuff is set
    up correctly? It would be nice to provide some feedback on
    whether it's set up correctly or not.

     
  • Jonathan Hedley

    Jonathan Hedley - 2002-12-05

    Logged In: YES
    user_id=661742

    I think the easiest would be to check the return code for `cvs
    co -c` or some such; if it's > 0, echo the error to the user.
    That way you don't need to know about the local
    implementation. (ssh checks are pretty detailed and way
    beyond the scope of cvsmonitor I think)

    If it's :ext: using ssh, and ssh isn't setup with an authorized
    key, it's going to prompt for a password. And if the host is not
    yet in known_hosts, it will ask to add it. I'm not sure what ssh
    will do when there's no tty attached. Perhaps it would be best
    to print a few newlines after opening a pipe to the cvs
    command, then close it and check $?

     
  • Nobody/Anonymous

    Logged In: NO

    ------------
    Obviously the web sever user needs to have an ssh identity
    and authorized key set up.
    ------------
    The web server user is nobody, then how can one get those
    setup? Any new thoughts?

     
  • Adam Kennedy

    Adam Kennedy - 2002-12-13
    • priority: 3 --> 5
     
  • Adam Kennedy

    Adam Kennedy - 2002-12-13

    Logged In: YES
    user_id=153576

    I'm leaving this for the moment, until I get 0.6.2 out the
    door, as it has a bunch of good things and significant fixes
    that shouldn't get held up.

    I have some ideas for a more generalised backend
    abstraction, which I'll start on for 0.7, to follow 0.6.2 ( or at
    least to branch ). The idea will be to move everything
    backend related into a single class, in this case
    CVSMonitor::Backend::pserver.pm, inheriting from the
    more generic CVSMonitor::Backend::CVS.pm. It should
    mean we can provide a different set of 'New Repository'
    forms, which can be customised with the relative
    information for admins setting it up. Also, after 0.7.X, we
    need to start thinking more seriously about Subversion
    support. Subversion should be close enough in use ( it's
    designed that way ) that once we have gotten comfortable
    with the generalised backend for 0.7, we can add
    CVSMonitor::Backend::Subversion.pm. After the release of
    0.6.2, there will be a while to just hunt everything down and
    pull it out ( for example the current CVSMonitor::MetaData::
    (Module|File|Version) constructors will have to go. Once
    I'm comfortable with the class layout and have
    Backend::pserver.pm working, I'll add local and ext
    support.

     
  • Adam Kennedy

    Adam Kennedy - 2003-01-21
    • assigned_to: nobody --> adamkennedy
     
  • Adam Kennedy

    Adam Kennedy - 2004-07-26
    • priority: 5 --> 7
    • milestone: --> Next_Release
     
  • Nobody/Anonymous

    Logged In: NO

    Hi,

    has support for non-pserver repositories been add to 0.7?

    Also, does anybody have a patch (even a nasty one) for
    adding support for :ext: ssh repositories, for 0.6.3 (or
    something similar)?

    Thanks,
    Ian.

     
  • Adam Kennedy

    Adam Kennedy - 2004-08-18

    Logged In: YES
    user_id=153576

    At this point, it's looking like 0.7.0 will be a "get it our
    the door as soon as everything is stable again" release.
    pserver CVS and perforce are probably the only backend.

    0.7.1 should hopefully add :local (with massive danger
    warnings), :ext and subversion (if the people that
    volunteered to write it come through).

    There has been the odd hack appear... I don't have it in
    patch form though. Mostly it involves doing really nasty
    things like running CVS Monitor using their personal user,
    which I would expect means that cvsmon has theoretical write
    mode to the repository. And I'm against that sort of thing.

    What really needs to happen is I need to chase down the CVS
    or ssh developers and grill them.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks