Re: Git
Hi
Bit late, but this may be helpful if you want to run your own repo
rather than using an outsourced site (github, etc)
http://github.com/sitaramc/gitolite
Then chuck up gitweb for the public web interface (or one of the many
others)
Hello, Guy. Do you have experience recovering a git clone from years
of historical mistakes in other version control systems? I could
really use that right now.
Fundamentally you have "git rebase -i" and gui tools equivalents
However, bear in mind that converting to git basically means just
checking out each revision in your original vcs, then copying the state
to the git repo and committing that change. Any import script will just
be a wrapper around that basic process and so you can write your own, do
it manually, etc
Currently the big hurdle moving to git is repairing damage caused by
years of newbie mistakes in RCS, CVS, and especially Subversion.
Funny you say that - one of the things I like about git is that I find
myself checking in 5 small changes with good comments versus 1 large
commit with a poor comment when I used SVN. I tended to use svn more
like a kind of "snapshot" system and git I use more like a historical
change record...
git-svn clone puts all the release tags up through 1.003 on the master
branch. Release tags after 1.003 (through the present) are on a
different branch. I haven't learned why trunk (therefore Master)
doesn't represent the most recent changes.
My guess is that there was a fork here and you have one of more commits
on the master branch which aren't in the 1.003 branch?
I would have thought running "git cherry" would show up differences and
then switch to the master branch and do a git merge from the 1.003
branch to fix it? (Incidently, don't really alter the real branches,
instead create a "wip" branch from master, then merge that with 1.003,
if there are any problems you can blow it away. Then when it's working
simply rename master (or delete it) and rename your wip branch to master)
POE::Test::Loops and POE::Loop::{Event,Gtk,Tk} were created by moving
files from trunk/poe to other directories in trunk. This seems to
have broken the files' revision chains. I'd like to regain that old
history. I'm considering cloning the git repository up until the
diversion point, rebasing a broken branch onto the clone, and then
deleting all the files the project doesn't need.
This sounds sane - actually it should be much easier to do this than you
think in git. First import everything, then remember every commit can
be used as a branch name, so just "git checkout a3354b1" and there you
go - right back at that old commit. Make it a proper named branch,
mangle the repo to your hearts content and then merge in all the rest of
the changes from the original branch. If you want to tweak any commits
then simply use "git rebase -i" and you can then juggle around the order
of patches, split one patch to be many patches, merge patches to be a
single change, etc. Always do all your work in a separate branch so that
you can blow it away if you don't like it
Also remember that git cherry is incredibly powerful for finding
unmerged changes. It will often even work through file renames and
large cut'n'paste changes (cool!)
I didn't read the original thread, so no idea if this is actually
helpful... Sorry
Good luck
Ed W
Re: POE::Component::Server::TCP bug fixes, possibly incompatible
Chris 'BinGOs' Williams wrote:
On Thu, Jul 16, 2009 at 12:59:09PM +0100, Ed W wrote:
Nick Williams wrote:
Regarding the passing of the socket into clientconnected - I've wished for
this in the past, in order to be able to modify TCP options on the socket,
which didn't seem possible in the past... It would be nice if that was
possible to get at this (either via some available API which I just haven't
noticed, or if these patches provide it at clientconnected time).
Indeed - I am toying with using POE for a rewrite of a fairly
sophisticated network proxy application over a very low bandwidth
connection and one of my initial questions would have been how to get
hold of the socket in order to set a bunch of badly documented OS
specific options on it (buffer sizes, etc)
Getting hold of the socket object at listen and connect time is very
valuable
You have access to the ReadWrite wheel in $_[HEAP]{client}, so you
have access to the socket via $_[HEAP]{client}->get_input_handle
Since this is all theoretical to me at this stage, then this sounds just
fine to me!
Ed W
Re: POE::Component::Server::TCP bug fixes, possibly incompatible
Nick Williams wrote: Regarding the passing of the socket into clientconnected - I've wished for this in the past, in order to be able to modify TCP options on the socket, which didn't seem possible in the past... It would be nice if that was possible to get at this (either via some available API which I just haven't noticed, or if these patches provide it at clientconnected time). Indeed - I am toying with using POE for a rewrite of a fairly sophisticated network proxy application over a very low bandwidth connection and one of my initial questions would have been how to get hold of the socket in order to set a bunch of badly documented OS specific options on it (buffer sizes, etc) Getting hold of the socket object at listen and connect time is very valuable Cheers Ed W
Re: Architecture advice requested
Hi
Rocco Caputo wrote:
It's unfair to ask for a comprehensive ("avoid as many dead ends as
possible") analysis of a complex system that is only described in
basic terms. The best anyone can do under these circumstances is
provide generic advice. Specific advice will invariably miss some
hitherto unexplained detail that invalidates the analyst's assumptions
and sets them back. Repeat for every mis- or insufficiently
understood detail, and the frustration (and time cost) mount. One set
of dead ends has been replaced with another.
Sure - agree completely. For that very reason I'm just trying to get
the skeleton roughly right first
The best way to break an application into POE entities is not to.
Decompose the application into entities and relationships that make
sense for the application. Determine the requirements first, then
apply POE to fulfill them.
OK, to be specific, the heart of it is a proxy server, which seems to be
fulfilled by using protocol X client wheel talking to protocol X server
wheel? The bits I guess I am most interested in are:
- How I might architect the POP server client to be one step removed
from the socket and have the following pipeline attached to the
socket: data_in -> decompress -> parse input data into separate
protocols and feed to correct wheel. Is this another wheel, or done as
a filter? (or something else?)
- Same for the output. ie taking the output of multiple wheels,
compressing the output and then blocking it into a simple protocol to
multiplex over a single TCP connection (just data packet with a header
on it)
- The main reason for looking at POE is that while it's mostly a
pipeline, occasionally one distinct bit of the app needs to talk to
another distinct bit, eg some remote end hangs up suddenly, the client
end may not be expecting this as part of it's normal protocol and we
need to wake it up and force it to terminate the other side of the
proxy. Any special features of POE which would be especially helpful here?
Thanks
Ed W
Re: Architecture advice requested
chris fedde wrote: My second reaction is to wonder if you can do better in perl than a demand dial PPP link would provide. ? You need both. At $1.50/min you want this dialup link only up when you need it Right now since most users are on windows we just show them the normal windows dialup feature and they dial when they need to do stuf My third reaction is to wonder if it is not better to use something like UUCP and batch load across the link. Hardly. Doing the algorithm described you are pretty close to a solid block of data moving in both directions simultaneously, including compression and management of tcp packet size. So the efficiency approaches that of UUCP + intensive compression, but both ends talk a standard protocol Interactive protocols like POP, IMAP, and HTTP are going to be very hard to use over such a slow high latency link. ?? That's why this project exists in the first place? Just to be clear: this exists already, I'm doing a structural enhancement. Current code is really only a few hundred lines at it's core, runs to a couple of thousand once you handle all the protocol parsing, gui and other special cases Download a trial from http://www.mailasail.com - the client is packed as an EXE, but I doubt that will stop an enterprising soul who wants to see how it works... If your goal is just email then I'd recommend setting up a local MTA and configure it to use ETRN to collect mail queued at an MTA on an internet connected host. OK, so that's only about 5x slower than my proposed solution. No compression and large latency due to each SMTP command being sent one by one. Don't forget that tcp slow start will also hurt you. I think my suggestion is much better... You'll also want very good spam filtering on the connected side to avoid paying for too much spam. Sure - done. Also we do a huge amount more like killing redundant email headers, eliminating extra HTML sections and optionally blackberry like attachment mangling into text. What I am really looking for are suggestions on how to structure a small proxy application which will really stretch the POE architecture because the outer layers are quite integrated with the inner layers The inner side of the app is presumably just going to be several wheels proxying to each other, eg pop server is the in side, talking to a pop client wheel which then goes back out to the network and the real server. However, given that I want to compress this output and multiplex it, is it best to call that an output filter? How might I signal to the output filter that I want the compression buffered at this point in the stream? How might I indicate that this stream should get priority over this other stream?) What about the receiving end which gets a compressed stream packing several protocols. There will need to be a bit of logic to handle corruption, invalid input, etc. Then it needs to unpack this into several protocol streams and feed them to several protocol parsers. Does that sound like an input filter or is it a wheel because there might be some state information (several packets to join, etc) Any thoughts? Any demo apps which show parts of this functionality? Thanks Ed W
