Re: [Zope-dev] FWIW, ZCVSMixin now at 0.1.1... and rising. ;-)

2000-07-01 Thread Steve Spicklemire


Hi Jim, et. al... 

 
 Steve and Shane,
 
 We've been positively *dying* to have cvs or cvs-like functionality. It's
 one of those things where we left the unix-everything-is-a-file-idiom and
 went, "Oh, um, heh, now what?" =)
 

Well.. I don't know much about cosource but I did just put the latest 
version on zope.org, with Shane's patches, and incorporating some of his
UI suggestions. (as much as I could get done in a few hours...)  I'm kinda
strapped for time right now.. since I'm working on active, deadline oriented
projects and all.. of course all contributions welcome! This latest for example
just saved me lots of time, since I was about to do the same thing Shane did
in a much less elegant way...  Thanks again Shane!

For what it's worth, we needed this so badly in my project that I was pretty
much forced to implement it, anyway I could! We are using now... and it's 
working pretty well for us. You have to 'understand' too much about what's
going on for my taste but it's getting better.

-steve



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] FWIW, ZCVSMixin now at 0.1.1... and rising. ;-)

2000-06-30 Thread Shane Hathaway

Steve Spicklemire wrote:
 I don't know if anyone out there is actually trying to
 *use* my ZCVSMixin/ZCVS Folder stuff, but if you are you certainly
 want to get the latest release, ZCVSMixin-0.1.1.tgz from
 the zope.org site:
 
 http://www.zope.org/Members/sspickle/ZCVSMixin

Hi, Steve.  This work looks very interesting.  I decided to try it out
and noticed it was not possible to manage a product folder with
ZCVSMixin, so I started hacking up your product.  (Images that resemble
a horror movie come to mind.) :-)

I've attached my changes in a private e-mail so as to not flood the
list.  Basically I made it possible to override the behavior of
ZCVSMixin so that it can manage a folder other than itself.  Then I
created a new class derived from ZCVSMixin which is a "CVS" Folder. 
That way, it's possible to manage any objects in the ZODB, regardless
of whether CVS had been considered in the structure.

 I put some screenshots up there so you can
 see what it looks like at:
 
 http://www.zope.org/Members/sspickle

It looks good, but the interface could be a lot cleaner.  I envision a
table with three distinct column groups: the ZODB version, the FS
version, and the repository (with details).

When the ZODB and FS are in sync, a small black equal sign will appear
between them (preferrably a graphic to make it more visible.)  When the
FS and repository are in sync, there will be a small equal sign between
them also.  When something is not in sync, a green arrow pointing in
the direction the file needs to go will replace the equal sign.

The buttons below would be placed in such a way to make their function
obvious.  In fact, the submit buttons could be images containing the
arrow icon.  Thus the interface would be simple and obvious.

 I've also found it useful for managing Python products and other
 software through the web! I have had a couple of minor 'breakthrough's
 that *seem* cool, but I might just be fooling myself. If an object is
 not folderish I guess that it's 'simple' so I export it as XML with
 the following code:

 (snip)

This looks good, Steve.

 If objects are 'folderish' or 'complex' (and the user is permitted to
 dictate this when objects are added to CVS), they are exported as
 'zexp' files and cvs adds them as 'binary'. I was having trouble with
 certain kinds of object's xml representation.  I decided that this was
 really an xml implementation problem, since I couldn't reliably export
 these as xml through the normal Zope export mechanism either. Anyway..
 let me know what you think if you are using this stuff!

I think we need to look into performing complete CVS checkouts which
create entire folder hierarchies.

 Finally I'm aware that there are also security issues with the way
 this works now. I need to look at all the things a user might need to
 do and eliminate some of the 'type in' arguments that are in the
 product now. These arguments wind up on 'os.system' calls, and could
 be abused by a ill-meaning user (with access to the CVS Admin page!)
 Any thoughts there?

Imagine this possibility: Zope would start what I'll tentatively call
an "execution proxy" server at startup.  When a user want to access CVS
through Zope, they would be required to start a background "execution
client" which makes a connection to Zope's execution proxy server. 
When the user accesses a CVS function in Zope, Zope would look at the
list of connected execution clients and ask the appropriate execution
client to access the file system and execute cvs commands based on that
user's system privileges.

Advantages:

- Unless a given user is running the execution client, the possibility
of intruders gaining access to that user's files is not increased.

- Nothing has to run with root privileges.  

- The execution proxy could run on a privileged port, making it
impossible for intruders to trick users into using a counterfeit
execution proxy (unless, of course, the intruder already has root
privileges.)

- No need for administrators to fiddle with filesystem permissions.

Disadvantages:

- If Zope is compromised while execution clients are connected, the
intruder may be able to execute commands through the execution
clients.  To reduce the impact, we can reduce the commands allowed to
be executed.  Note, however, that this problem is very likely inherent
in CVS access through the web.  Even the current implementation suffers
from this problem.

- Users will have to manually start their execution clients, which will
stop automatically when they log out.  This is actually designed to be
an advantage in terms of security.  On the other hand, it would be
possible to write an execution client that runs as root and
automatically spawns child clients for each user.  That could be
dangerous, though.

It should be relatively easy to write all this IMHO.

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross 

Re: [Zope-dev] FWIW, ZCVSMixin now at 0.1.1... and rising. ;-)

2000-06-30 Thread Jim Hebert

Steve and Shane,

We've been positively *dying* to have cvs or cvs-like functionality. It's
one of those things where we left the unix-everything-is-a-file-idiom and
went, "Oh, um, heh, now what?" =)

We have been making do with Version objects instead, which are far more
rcs-like (exclusive locking, no merging) and not really good when we want
to give 2 different people 2 different medium-to-long term projects for
adding things to the site. Imagine, one adds something to / and / gets
version-locked now, so the other person can't even add things to /
anymore.

Anyways, enough of that. Point being, we want our site coders to be able
to do a sandbox (much like Version essentially provides, if possible, ie
transparent rather than explicitly located somewhere else) where they can
develop stuff and the ability to only check certain things in, and the
ability to do merges, etc. If we couldn't do the development transparently
on the production server, and we had to have developers running zope on
their workstations and pull from the cvs repository there, that'd be
alright too though I guess.

How much of this is provided for now or planned on being provided for by
this product? And, what can we do to help? I don't know that we have any
bodies we can sick on this, but I'd love to get together with you guys and
get some of the things that need to be done up on Cosource so that
organizations interested in having this can throw money at it, and so that
people (you guys included) who might have trouble finding the time to work
on it can have a little incentive. =)

jim

-- 
Jim Hebert   http://www.cosource.com/
[EMAIL PROTECTED]  The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical" -- Alan Cox




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )