Put bzr update in cron?
Or if you want an exact copy of trunk, use 'bzr branch' then 'bzr
pull' to keep it in sync.
On 23 January 2014 20:53, Eliezer Croitoru elie...@ngtech.co.il wrote:
Since I do have a local server I want to have an up-to-date bzr replica.
I can just use checkout or
On 23/01/2014 7:19 p.m., Eliezer Croitoru wrote:
On 07/01/14 11:52, Amos Jeffries wrote:
Updated patch attaced for audit.
SNIP
I do not see any patch in the mailing list post, Are we talking about
This one with the mk2 patch actually attached.?
Yes.
Amos
On 22/01/2014 10:32 p.m., Henrik Nordström wrote:
tis 2014-01-21 klockan 22:45 -0700 skrev Alex Rousskov:
All the TCP clients and servers you are willing to include (as future
TcpReceiver kids) in the current project scope have at least one thing
in common -- they all read and write protocol
tor 2014-01-23 klockan 09:53 +0200 skrev Eliezer Croitoru:
Since I do have a local server I want to have an up-to-date bzr replica.
I can just use checkout or whatever but I want it to be be updated etc.
I am no bzr expert so any help about the subject is more then welcome.
What I do is that
Hi,
my 2c.
I use a more centralized approach:
bzr co bzr+ssh://remote.addr/repo
and then just bzr ci, optionally --local if I am disconnected.
On Thu, Jan 23, 2014 at 10:38 AM, Henrik Nordström
hen...@henriknordstrom.net wrote:
tor 2014-01-23 klockan 09:53 +0200 skrev Eliezer Croitoru:
Since
On 22/01/2014 6:45 p.m., Alex Rousskov wrote:
On 01/07/2014 02:52 AM, Amos Jeffries wrote:
Updated patch attaced for audit.
This one includes all the currently known bits for server-side delay
pools so no audit omissions this time around.
On 4/01/2014 8:16 a.m., Alex Rousskov wrote:
On
See http://build.squid-cache.org/job/3.HEAD-coadvisor/180/
--
Started by an SCM change
Building remotely on co-advisor in workspace
http://build.squid-cache.org/job/3.HEAD-coadvisor/ws/
Cleaning workspace...
$ bzr checkout --lightweight
On 2/11/2013 2:11 a.m., Amos Jeffries wrote:
Hi all,
As some of you are no doubt aware that one of the design issues we are
facing with Squid these days is the process model. The current model has
a very init.d centric design and shoots itself in the foot when
encoutering third-party daemon
