I think all we want is to sync two directories (we can forget about the r from rsync).
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 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=3026No, we should leave GPL code alone, because the GPL license is viral.
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.
I don't know the Python world to know if we oughtSync 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
'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.
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.
I tried to hack the code in forrest.py where the seed command is called, but hacked it badly.youBTW: How long does it 'hang' in forrest? How big is your workspace? [If
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 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]
