Re: Abstract of git push pull to plone app theming.concepts

On 19 Mar 2014, at 4:19 am, Krishna Teja <[email protected]> wrote:

> Can you please review the below mail and tell me if i am wrong in any case. Actually its a part of my proposal and i just want to know if i have done any mistake in this:
> 
> 
> When developer want to edit the theme the memory repo is initialized

I'm not sure what you mean by initialized here. initialization has a specific meaning in git that only refers to when a repo is first created rather then when someone is about to make a commit.

> and the git backend is brought to the memory from the ZODB and all the changes made are recorded in dulwich’s persistent python objects. On issuing a commit these objects are added to the in memory git repo. On issuing a checkout to previous state or another branch the portal resource objects containing the theme are modified from the snapshots present in git to the state referred by checkout command. Hence the changes happen to the site live. When the editing work is complete a transaction.Commit() command is issued and Zope transaction manager will automatically update all these changes in the ZODB and the transfer takes place using the ZEO.
> 
> 
> 
> 
> The python library Dulwich required for our project is already present. Our main task will be to code the dulwich git repo and integrate this git repo with Zope interface manager, theme control panel and portal resource objects. The changes made to theme are stored as blob objects.

Nothing is stored as a blob to my knowledge.

> The file system structure and the reference or mapping to blob objects is stored in tree object. Finally the commit contains the reference to previous commit, the tree object, developer details, time-stamp and a message. Since branching facility is also provided we need to keep a track on the various branch heads and the commits pointed by these heads. When author issues a checkout to previous state or another branch the head has to be moved to previous commit state or the commit pointed by the branch head. The changes to the portal resource objects has to be done accordingly, Sometimes conflict may arise while merging and we have to take care to resolve this automatically. The git repo must work even if the changes are made from Plone or from a production server or while editing purely online.

The fact that you are mentioning merging here means that haven't understood the full use case proposed, in that each edit in the theme editor is atomic and results in a commit and the transactions of ZODB mean that a push and a commit can't occur at the same time so no merging is needed.

> 
> 
> 
> 
> The git repo will have the structure that is used by ZODB to store object. Some features must also be automated like initializing the repo when changes are to be made, adding newly created theme files for tracking and deleting the branch automatically after merging is done. To improve the efficiency packaging and compressing have to be taken care of. The developer is presented with options like commit (to save a state), checkout (to revert to previous commit), log (see the list of all commits,), status (contents in staging area,), diff (difference between two commits), reset, branch, merge. We will be using a message box to display the results for commands like Log, Show, diff, and this feature must be added in theme control panel. A better user interface for these commands has to be provided in the control panel in the form of buttons. If the developer wants to download the theme then the Git repo will be zipped in a .git folder and the developer can upload it in another site and test it along with the backend (optional feature)

I'm afraid you would need to demostrate a lot more knowledge of ZODB programming and of how the theming interface currently works to be successful at this proposal. I'd suggest that while this proposal doesn't require an indepth knowledge of plone it does require an indepth knowledge of the ZODB and some kind of demonstration of that. I'd suggest you try for a less advanced idea. If you go back through the threads, there were plenty of ideas that didn't even make it to the plone.org list of ideas.


> 
> 
> 
> 
> On Fri, Mar 14, 2014 at 12:28 AM, krishnatejaperannagari <[email protected]> wrote:
> portal resource objects in the sense the theme is stored in the zodb
> internally as resource objects
> 
> Zodb stores everything in the form of oobuckets and oobtrees.Even the git
> repo will have the same format.rhe contents of a folder are stored in the
> form of nodes of a branch(like a tree hiereachy)for example the git objects
> wil be under the object branch.
> 
> We will create all git objects by using persistence.so the http request will
> fetch the data and  When the HTTP request completes, Zope transaction
> manager will automatically update all changed persistent objects to the
> database.there is no need of pushing or pulling
> 
> sometimes developers clone entire repo to their local disk make
> modifications to theme and then push them back.in this case we need to add
> remote repository references,remote heads for heads in the repository and
> also setup one head to track changes in local repo.
> 
> *i cannot find branch merge pull and push in dulwich docs.if thats not
> present then we must restrict the idea to only one branch and one
> developer.but we get advantage of all git featuresonly clone and fetch are
> present in dulwich.*
> 
> 
> *however to summarize the git workflow will be as follows:*
> when developer wants to modify the theme the repo is initiated he will first
> choose the head.when there are branches the developer decides which branch
> he wants to work and then chooses the appropriate head,in case of a cloned
> repo the head will be the one that is set to track changes in the local repo
> 
> the files that appear are derived from the commits that the chosen head
> points to.I have a doubt abou*t how this is done in object oriented databse
> where theme is resource object?*
> 
> wen the changes are saved a new commit is made and the corresponding head
> now points to the new commit.
> 
> the options that will be present to developers are:
> branch, commit checkout(switch branch or go to old state),pull push log.
> 
> 
> 
> 
> --
> View this message in context: http://plone.293351.n2.nabble.com/Re-Abstract-of-git-push-pull-to-plone-app-theming-concepts-tp7570525p7570603.html
> Sent from the Core Developers mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers
> 
> 
> 
> -- 
> krishna teja perannagari
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech_______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech