gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: various gump remarks/problems
Date Tue, 24 Feb 2004 21:19:23 GMT
> 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.

Works for me.

> I am willing to write it.

Works best of all.

> 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.

If you do write it this way, a few thoughts:

1) I use 'cp' (even when rsync is available) to copy the forrest template
into a work tree, and then copy a local (site) forrest template on top [if
available]. We can't rsync the second because we'd loose the main template.
Your sync w/o the following deletions would maek a good copy.

2) I suspect that os.walk would be a beautiful thing here, but we are trying
(for a short while longer only, I hope) keep to Python 2.2 & not force 2.3.

3) Anything in dircmp useful?

4) Right now gump/utils/ would seem appropriate. An interface that
logged debug/info/warn/error, and raise issues when critical would be fine
for me to wire into Gumpy. I don't think a file by file output is needed, or
anything other than 'it failed to do as you ask', but if so I can help you
w/ annotated objects (notes) and such.

5) A unit test (home grown gump/test/ would be awesome. Perhaps
extend gump/test/ which now conttains the (not yet removed)
listDir/catFile AsWork and ToFileHolder (the replacements.)

> 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.

CVS and/or SVN (and that one template dir of dirs/plain files, taken from
Gump CVS tree) so yes -- no need for complexity, I feel.

> 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.

CVS/SVN(/Ruper)(/Maven) are all fine by me to have external for the
foreseable. The other thing we launch, pgrep, is a pain but I don't know a
pure Python way to detect child processes in order to kill them (in a

> put the
> content back and run forrest by hand and it looks like it is working.

Awesome. Forrest might be a tad heavyweight for our needs, but I really want
to persist with it and keep Gumpy simple. Writing more than xdocs would
likely lead to 'getting pretty' (read browser woes), and all sorts of
unnecessary time wasting stuff. That, and I think forest sites look snappy &
enjoy standing on their shoulders.



View raw message