ZCVS Mixin class... feedback sought.
Chris Withers wrote:
Sounds like a cool idea, but I don't really understand what it does and how you use it.
Could you give use some enlightenment?
Have a little patience with Steve, to him reading Python source code is like reading our own native language to the rest of us. "Docs, we don't need no stinkin' docs!" ZCVSMixin is a sort of replacement for a standard Zope Folder Object. If you want to be able to maintain an entire Zope Folder (and everything in it) in CVS, use a ZCVSMixin Object instead. Then, from the Manage view, you get a new tab showing up that provides the interaction with CVS. What it actually does is an Export as XML on the whole "folder", which then can be stored, view, checked out, checked back in, and otherwise thoroughly managed and maintained within CVS. For developers that are deep into Zope, and familiar with CVS, this represents some potent possibilites. Think about checking out a Zope Widget from a CVS on the other side of the planet, importing as XML into your local Zope, where it is marshalled back from its CVSish XML form into the original native Zope self. Now you can tweek it to your hearts content, export as XML, then check the updated version back in, where it becomes part of the trackable, archived, searchable CVS system. Steve, please clarify any of the concepts I've managed to mangle!
Jerry Spicklemire wrote: [snip]
Steve, please clarify any of the concepts I've managed to mangle!
Now this sounds like something I waffled about a few weeks back... ...cool :-) I don't think I'm gonna have a chance to play though :S I'll jump in at 1.0.0 though and I'm there in spirit now ;-) Good luck, Chris
Hi Jerry, (in case you're wondering.. Jerry really *is* my brother..)
"JS" == Jerry Spicklemire <jerry@spicklemire.com> writes:
JS> Chris Withers wrote: >> Sounds like a cool idea, but I don't really understand what it >> does and how you use it. >> >> Could you give use some enlightenment? JS> ZCVSMixin is a sort of replacement for a standard Zope Folder JS> Object. If you want to be able to maintain an entire Zope JS> Folder (and everything in it) in CVS, use a ZCVSMixin Object JS> instead. Then, from the Manage view, you get a new tab showing JS> up that provides the interaction with CVS. That's basically right. Technically there are two parts. ZCVSMixin is a python "Product" that handles talking to CVS and importing and exporting objects. There is also a ZClass that inherits from both Folder, and ZCVSMixin to provide Folder behavior and methods while adding CVS support, hence the name Mixin. I believe you could really use the 'Mixin' to add CVS support to any subclass of ObjectManager, in a similar way. JS> What it actually does is an Export as XML on the whole JS> "folder", which then can be stored, view, checked out, checked JS> back in, and otherwise thoroughly managed and maintained JS> within CVS. For developers that are deep into Zope, and JS> familiar with CVS, this represents some potent possibilites. Well.. close! It exports and imports all the objects in the folder individually. This way I can edit one method, then 'checkin' that change with CVS. Anyone else with access to my repository can do a 'checkout' from their Zope and get all the latest versions of my objects in their zope. Think of it as the public CVS that CD uses now to publish Zope itself, but taken to the level of tracking individual zope objects contained in Zope folders. I've just been playing with it.. and you can sorta get the idea looking at: http://cvs.spvi.com/cgi-bin/viewcvs.cgi/zopeObjs/testCVS/ With CVS you can tag revisions etc and take a snapshot in time of your zope objects, just like we do now with source code. JS> Think about checking out a Zope Widget from a CVS on the other JS> side of the planet, importing as XML into your local Zope, JS> where it is marshalled back from its CVSish XML form into the JS> original native Zope self. Now you can tweek it to your hearts JS> content, export as XML, then check the updated version back JS> in, where it becomes part of the trackable, archived, JS> searchable CVS system. Right... that's the idea. JS> Steve, please clarify any of the concepts I've managed to JS> mangle! Hope that helps.... It's really shocking just how easy it was to do this.... makes me wonder why it hasn't been done already, and *that* makes me wonder if I'm doing something really dumb here. ;-) It seems kinda cool to me. -steve
Steve Spicklemire wrote:
Hope that helps.... It's really shocking just how easy it was to do this.... makes me wonder why it hasn't been done already, and *that* makes me wonder if I'm doing something really dumb here. ;-) It seems kinda cool to me.
I find that the same phenomenon keeps occurring for the things I've been doing as well. Transparent folders, product refresh, and even mounted databases all turned out to be a lot simpler than anyone thought they would be. Makes it fun to be a software engineer, don't you think? Shane
Just curious. How do you do diffs? How do you resolve conflicts? How do you handle login/logout? --jfarr "Perl is worse than Python because people wanted it worse." Larry Wall, 14 Oct 1998
Hi Jonothan, Good questions! You can just go to the 'admin' tab and type 'diff'. The admin tab lets you execute just about any cvs command with arguments.... stat, rtag etc etc..... Conflicts.. uh... bad news. ;-) I think it's essentially impossible to 'merge' two different versions of a zope object... so my plan would be to pick one version, or the other. Login and logout are handled when you set up the directory on the filesystem. Basically you need to 'checkout' a module (maybe an empty module) into a directory on the filesystem before you can use it to keep the xml representations of your Zope objects. That checkout, might, or might not, require a login, depending on your CVSROOT. You must 'be' the zope user (the same user that the zope process runs as) when you checkout the module, so that zope can manage the contents. thanks, -steve
"Jonothan" == Jonothan Farr <jfarr@real.com> writes:
Jonothan> Just curious. How do you do diffs? How do you resolve Jonothan> conflicts? How do you handle login/logout? --jfarr
Good questions!
You can just go to the 'admin' tab and type 'diff'. The admin tab lets you execute just about any cvs command with arguments.... stat, rtag etc etc.....
Doing a diff on a zexp file isn't going to be very helpful, though. Any thoughts on integrating some sort of xml diff tool?
Conflicts.. uh... bad news. ;-) I think it's essentially impossible to 'merge' two different versions of a zope object... so my plan would be to pick one version, or the other.
Login and logout are handled when you set up the directory on the filesystem. Basically you need to 'checkout' a module (maybe an empty module) into a directory on the filesystem before you can use it to keep the xml representations of your Zope objects. That checkout, might, or might not, require a login, depending on your CVSROOT. You must 'be' the zope user (the same user that the zope process runs as) when you checkout the module, so that zope can manage the contents.
So essentially all checkins are by the same cvs user, so you lose the ability to track accountability? I'd like to see something that was on a per-user basis, maybe tied to the zope user, maybe not. There's been a ton of talk about a zope cvs product. I've been thinking about giving it a shot for a while now. I'm excited to see someone actually doing something about it. I'd be glad to help out however I can. Especially since now you've taken the killer name. ;) --jfarr
Hi Jonothan, Thanks for the thoughts....
"Jonothan" == Jonothan Farr <jfarr@real.com> writes:
>> Good questions! >> >> You can just go to the 'admin' tab and type 'diff'. The admin >> tab lets you execute just about any cvs command with >> arguments.... stat, rtag etc etc..... Jonothan> Doing a diff on a zexp file isn't going to be very Jonothan> helpful, though. Any thoughts on integrating some sort Jonothan> of xml diff tool? Not as bad as you might think... http://cvs.spvi.com/cgi-bin/viewcvs.cgi/zopeObjs/testCVS/foobie.xml.diff?r1=... having said that .... and xml diff tool would be cool as well. I know little/nothing about what's out there. The other problem is that Zope appears to choose id values for pickles embedded in these xml files that are essentially random. I don't know enough about the implementation (time to look?) to know why they choose the ids they choose... but it would be nice for this reason if they were always, (usually), consistent. You also get things like this: http://cvs.spvi.com/cgi-bin/viewcvs.cgi/zopeObjs/testCVS/foo.xml.diff?r1=tex... >> Conflicts.. uh... bad news. ;-) I think it's essentially >> impossible to 'merge' two different versions of a zope >> object... so my plan would be to pick one version, or the >> other. >> I forgot to mention that you have all the power of CVS to handle the notion of 'watching' and 'editing'. I'm not a cvs expert.. but I think there are some cvs features that can help here... >> Login and logout are handled when you set up the directory on >> the filesystem. Basically you need to 'checkout' a module >> (maybe an empty module) into a directory on the filesystem >> before you can use it to keep the xml representations of your >> Zope objects. That checkout, might, or might not, require a >> login, depending on your CVSROOT. You must 'be' the zope user >> (the same user that the zope process runs as) when you checkout >> the module, so that zope can manage the contents. Jonothan> So essentially all checkins are by the same cvs user, so Jonothan> you lose the ability to track accountability? I'd like Jonothan> to see something that was on a per-user basis, maybe Jonothan> tied to the zope user, maybe not. No.. that's not quite right. CVS has several ways to handle the concept of 'ownership'. If you are using pserver authentication for example, you can be user x, but authenticate with cvs as user y. So, to make this work Joe would have his branch and mary could have her branch in different ZCVSMixin folders within the same zope instance. However, for development I think it's probably not uncommon that individual zope developers might have their own zope instance. With a ZCVS Mixin folder they could work on completely seprarate instances and still stay 'synced', much the same way developers use cvs to stay synced with 'c' code now. Jonothan> There's been a ton of talk about a zope cvs Jonothan> product. I've been thinking about giving it a shot for a Jonothan> while now. I'm excited to see someone actually doing Jonothan> something about it. I'd be glad to help out however I Jonothan> can. Especially since now you've taken the killer Jonothan> name. ;) I haven't heard much of the talk, since I have been too busy to keep up with the list, but I am interested in ideas. Also.. I'm 72% sure that someone else can come up with a much better name! ;-) thanks, -steve Jonothan> --jfarr
participants (5)
-
Chris Withers -
Jerry Spicklemire -
Jonothan Farr -
Shane Hathaway -
Steve Spicklemire