rsync.py - http://www.vdesmedt.com/~vds2212/rsync.html
--- Antoine_L�vy-Lambert <[EMAIL PROTECTED]> wrote: > Adam R. B. Jack wrote: > > > > >Could you take on a challenge that I've not been able to, yet? Rsync ... it > >is a major pain, 'cos it has bugs [not deleting what it ought] & 'cos it is > >not pure Python. There are Python choices (thanks Nicola for the original > >reference) but we'd need to weigh these verse writting our own: > > > > > > > I think all we want is to sync two directories (we can forget about the > r from rsync). > I think we better have our own, but we can use outside inspiration. > I am willing to write it. > > >http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=3026 > > > >http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/231501 > > > >http://sourceforge.net/projects/dirssync/ > > > >http://www.homepages.lu/pu/dfp.html > > > >I don't know the OSS world well enough to know if we can use GPL code, > >bundle it, whatever. > > > No, we should leave GPL code alone, because the GPL license is viral. > > >I don't know the Python world to know if we ought > >'expect' packages installed, or (like we did w/ logging) we ought dump them > >in our CVS. Are you able to look into this, and select a solution? If you > >get one, I'd work with you to get it into Gumpy. > > > > > Sync is simple enough (to me) so that we write our own solution. I think > it is just a recursive copy (possibly skipping files which have same > datetime and size > at source and destination), then a deletion of files which exist at > destination and do not exist at source. I am willing to write the stuff. > > I think we can start with a very basic implementation, ignoring symlinks > and file permissions issues. I understand we are mostly syncing CVS > trees which I don't think contain symlinks, and where all the files > are read write. If needs be we can always make it more complicated. > > >BTW: If we port all these, would we not needs cgywin? I'm hoping not. > > > > > > > If we port all these, then we do not need cygwin any more. What we do > need is a cvs client, people setting up Gump instances > on M$ can choose between a Win32 or a cygwin cvs client, both can work. > > >>>BTW: How long does it 'hang' in forrest? How big is your workspace? [If > >>> > >>> > >you > > > > > >>>don't have forrest on the path it ought use text...] > >>> > >>> > >>> > >>I have seen messages on the screen running Forrest Documenter and > >>running Text Documenter, I do not remember in which order. > >>It took ages, and in the end my CPU was all eaten, I could not start > >>another program. > >> > >> > > > > > > > I tried to hack the code in forrest.py where the seed command is called, > but hacked it badly. > I have just tried to run forrest by hand, and it was complaining about > the skinconf.xml missing a <toc> element, > then about other files missing. > Now I moved temporarily my content, then run forrest seed, put the > content back and run forrest by hand and it looks like it is working. > Cheers, > Antoine > > >The Forrest Documenter does (as one page inside itself) run the Text > >Documenter [which we need to update to be nicer] so it is running Forrest. > >Gumpy needs to be smarter about documentation choices, but for now forrest > >ought be ok. I can't think why it chewed your CPU. Can you go to the forrest > >directory under your work area & run forrest by hand? Alternatively, what > >did the forrest.txt file show? [I forget if Gumpy sets --debug on forrest or > >not.] > > > >regards, > > > >Adam > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ===== Davanum Srinivas - http://webservices.apache.org/~dims/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
