From boxbackup at fluffy.co.uk  Mon Oct  3 15:26:31 2005
From: boxbackup at fluffy.co.uk (Maarten van Lieshout)
Date: Mon, 3 Oct 2005 16:26:31 +0200 (CEST)
Subject: [Box Backup] Symbolic links
Message-ID: <47601.62.58.195.244.1128349591.squirrel@webmail.vianetworks.nl>

Does Boxbackup follow symbolic links during backup? If so, can I disable
this for a given directory?

regards,

--
Maarten




From boxbackup at fluffy.co.uk  Mon Oct  3 15:30:05 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Mon, 3 Oct 2005 15:30:05 +0100
Subject: [Box Backup] Symbolic links
In-Reply-To: <47601.62.58.195.244.1128349591.squirrel@webmail.vianetworks.nl>
References: <47601.62.58.195.244.1128349591.squirrel@webmail.vianetworks.nl>
Message-ID: <8BA110EC-EA2D-4111-9AED-746D085DC2A3@fluffy.co.uk>

On 3 Oct 2005, at 15:26, Maarten van Lieshout wrote:

> Does Boxbackup follow symbolic links during backup? If so, can I  
> disable
> this for a given directory?

Symlinks are stored, not followed. So if you restore, you will get  
the symlink back.

In general you can exclude anything if you know it's name using  
directives in the .conf file.

Ben





From boxbackup at fluffy.co.uk  Wed Oct  5 08:41:16 2005
From: boxbackup at fluffy.co.uk (Prashant N)
Date: Wed, 05 Oct 2005 13:11:16 +0530
Subject: [Box Backup] Backup Subversion
Message-ID: <200510050659.MAA21075@WS0005.indiatimes.com>

Hi List,

Is it possible to backup the subversion repository with the options like full/incremental/differential ? If so how should i do this?

Thanks
Regards
Shann
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com

 Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com

Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now!



From boxbackup at fluffy.co.uk  Wed Oct  5 09:47:43 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Wed, 5 Oct 2005 09:47:43 +0100
Subject: [Box Backup] Backup Subversion
In-Reply-To: <200510050659.MAA21075@WS0005.indiatimes.com>
References: <200510050659.MAA21075@WS0005.indiatimes.com>
Message-ID: <526D40C8-3CA9-4B21-B490-D4EA1051790E@fluffy.co.uk>

On 5 Oct 2005, at 08:41, Prashant N wrote:

> Hi List,
>
> Is it possible to backup the subversion repository with the options  
> like full/incremental/differential ? If so how should i do this?

What's wrong with just letting Box Backup get on with it?

If your repository is in the recommended fsfs filesystem type, when  
you commit you simply get an extra transaction file. If you are using  
the db filesystem, then you will just get lots of copies of the  
repository database on the server, each stored as the differences  
from the later version.

Ben







From boxbackup at fluffy.co.uk  Wed Oct  5 10:20:43 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Wed, 05 Oct 2005 10:20:43 +0100
Subject: [Box Backup] Backup Subversion
In-Reply-To: <200510050659.MAA21075@WS0005.indiatimes.com>
References: <200510050659.MAA21075@WS0005.indiatimes.com>
Message-ID: <20051005102043.mooqjwif40kc0ok8@ebourne.me.uk>

Prashant N <myprashu at indiatimes.com> wrote:
> Is it possible to backup the subversion repository with the options 
> like full/incremental/differential ? If so how should i do this?

Somewhat depends on how your repository is set up.

If you're using the berkeley db backend (the default before svn 1.2) 
then you should really dump the repository using svnadmin and back up 
that up. This is because you can't be sure that the files are in a 
consistent state when they are backed up.

Having said that, if your repository changes slowly then you can get 
away with it (I have restored a bdb based repository successfully, but 
it rarely changes).

If on the other hand you're using the fsfs backend (the default since 
svn 1.2) then that is completely safe to backup with box. It also has a 
bunch of other advantages, so I'd advise if you're not using it already 
to dump your exisiting repository and rebuild it as fsfs.

As to special options, none are needed. Just make sure the repository 
is covered by box backup and it'll take care of the rest.

Cheers,

Martin.


From boxbackup at fluffy.co.uk  Wed Oct  5 17:20:06 2005
From: boxbackup at fluffy.co.uk (dave bamford)
Date: Wed, 05 Oct 2005 17:20:06 +0100
Subject: [Box Backup] Client on Win XP 64
Message-ID: <4343FD36.2050508@logical-progress.com>

Tried installing the client binary version h on a box running
XP64 with an Athlon 64.

As I expected it failed to run. Has anyone tried compiling for this platform
yet?

Dave Bamford.


From boxbackup at fluffy.co.uk  Thu Oct  6 09:10:21 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Thu, 6 Oct 2005 09:10:21 +0100
Subject: [Box Backup] Client on Win XP 64
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F930C16F@toutatis.omn11s.local>

No - but I can add it to the list, I can try to compile - but I will
have nothing to test it on - unless anyone want to donate some
hardware:)

Nick

-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
On Behalf Of dave bamford
Sent: 05 October 2005 17:20
To: boxbackup at fluffy.co.uk
Subject: [Box Backup] Client on Win XP 64

Tried installing the client binary version h on a box running
XP64 with an Athlon 64.

As I expected it failed to run. Has anyone tried compiling for this
platform
yet?

Dave Bamford.
_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Mon Oct 10 14:19:03 2005
From: boxbackup at fluffy.co.uk (Maarten van Lieshout)
Date: Mon, 10 Oct 2005 15:19:03 +0200 (CEST)
Subject: [Box Backup] Timezone
Message-ID: <33311.62.58.195.244.1128950343.squirrel@webmail.vianetworks.nl>

Hi,

I get 2-hours difference in my backup:

query > list -t
0001b870 f----- 2005-10-03T12:39:42 test.txt


[root at dev test123]# ll
total 0
-rw-r--r--    1 root     root            0 Oct  3 14:39 test.txt


Is there a parameter for this timezone thingy?

grtzs,

--
Maarten




From boxbackup at fluffy.co.uk  Tue Oct 11 14:42:09 2005
From: boxbackup at fluffy.co.uk (Wolfgang Trexler)
Date: Tue, 11 Oct 2005 15:42:09 +0200
Subject: [Box Backup] New Debian Packages?
Message-ID: <434BC131.2010509@trexler.at>

Hi,

I just found out, that debian.myreseau.org provides new debian boxbackup 
packages. As I've not read anything about it on this list, I was just 
curious what's the reason for this update (and if it's an official one).

apt-get -s update

Reading Package Lists...
Building Dependency Tree...
The following packages will be upgraded:
   boxbackup-client boxbackup-server boxbackup-utils
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst boxbackup-client [0.09-2] (0.09-3 debian.myreseau.org)
Inst boxbackup-server [0.09-2] (0.09-3 debian.myreseau.org)
Inst boxbackup-utils [0.09-2] (0.09-3 debian.myreseau.org)
Conf boxbackup-client (0.09-3 debian.myreseau.org)
Conf boxbackup-server (0.09-3 debian.myreseau.org)
Conf boxbackup-utils (0.09-3 debian.myreseau.org)

regards
Wolfgang


From boxbackup at fluffy.co.uk  Tue Oct 11 15:07:07 2005
From: boxbackup at fluffy.co.uk (Wolfgang Trexler)
Date: Tue, 11 Oct 2005 16:07:07 +0200
Subject: [Box Backup] New Debian Packages?
Message-ID: <434BC70B.5020607@trexler.at>

Hi,

I just found out, that debian.myreseau.org provides new debian boxbackup
packages. As I've not read anything about it on this list, I was just
curious what's the reason for this update (and if it's an official one).

apt-get -s update

Reading Package Lists...
Building Dependency Tree...
The following packages will be upgraded:
   boxbackup-client boxbackup-server boxbackup-utils
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst boxbackup-client [0.09-2] (0.09-3 debian.myreseau.org)
Inst boxbackup-server [0.09-2] (0.09-3 debian.myreseau.org)
Inst boxbackup-utils [0.09-2] (0.09-3 debian.myreseau.org)
Conf boxbackup-client (0.09-3 debian.myreseau.org)
Conf boxbackup-server (0.09-3 debian.myreseau.org)
Conf boxbackup-utils (0.09-3 debian.myreseau.org)

regards
Wolfgang



From boxbackup at fluffy.co.uk  Wed Oct 12 11:16:42 2005
From: boxbackup at fluffy.co.uk (Eelco Leenen)
Date: Wed, 12 Oct 2005 12:16:42 +0200
Subject: [Box Backup] temporarily stop sync
Message-ID: <e86b0357126a1c42ba3ff21683d0de8e@62.58.195.244>

Hello,

The initial backup from the server of our clients can be quite large (> 20
Gb). Since the upstream capacity is limited, we don't want to consume the
bandwidth during normal business hours. What's the best way to achieve a
temporarily stop of the sync ? (let's say from 7:30 am till 0:00 am)

I can see an option in the configuration file 'SyncAllowScript' which should
be able to cover the above. But, since no examples are provided, I don't
have any idea how.

An option could be to kill the daemon and then later restart it again
followed by a sync command. But, imo, this solution is quite nasty.

Thanks ! 




From boxbackup at fluffy.co.uk  Wed Oct 12 11:30:40 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Wed, 12 Oct 2005 11:30:40 +0100
Subject: [Box Backup] temporarily stop sync
In-Reply-To: <e86b0357126a1c42ba3ff21683d0de8e@62.58.195.244>
References: <e86b0357126a1c42ba3ff21683d0de8e@62.58.195.244>
Message-ID: <F594A76E-704B-4395-8CEF-874B0F06E746@fluffy.co.uk>

On 12 Oct 2005, at 11:16, Eelco Leenen wrote:

> Hello,
>
> The initial backup from the server of our clients can be quite  
> large (> 20
> Gb). Since the upstream capacity is limited, we don't want to  
> consume the
> bandwidth during normal business hours. What's the best way to  
> achieve a
> temporarily stop of the sync ? (let's say from 7:30 am till 0:00 am)
>
> I can see an option in the configuration file 'SyncAllowScript'  
> which should
> be able to cover the above. But, since no examples are provided, I  
> don't
> have any idea how.

There should be some notes in the .conf file. But your script just  
outputs, on a line with a terminating newline, either a number of  
seconds to delay the sync, or 'now' to let the sync go ahead.

However, it won't stop a sync in progress, so you can't use it.

>
> An option could be to kill the daemon and then later restart it again
> followed by a sync command. But, imo, this solution is quite nasty.

It's your only option, I think. And will work fine, it's written to  
cope with unexpected things happening. However, it will need to  
download the directory listing from the server when it restarts,  
which will take a little while.

Try it and see.

But... personally what I would do is use your platform's packet  
filter to throttle the bandwidth used during working hours. It's  
trivial using pf under OpenBSD, and I'm sure other platforms must  
have done something similar by now.

Ben





From boxbackup at fluffy.co.uk  Wed Oct 12 11:50:31 2005
From: boxbackup at fluffy.co.uk (=?ISO-8859-15?Q?J=E9r=F4me_Schell?=)
Date: Wed, 12 Oct 2005 12:50:31 +0200
Subject: [Box Backup] New Debian Packages?
In-Reply-To: <434BC70B.5020607@trexler.at>
References: <434BC70B.5020607@trexler.at>
Message-ID: <434CEA77.5090103@myreseau.org>

Wolfgang Trexler a ?crit :
> Hi,
> 
> I just found out, that debian.myreseau.org provides new debian boxbackup
> packages. As I've not read anything about it on this list, I was just
> curious what's the reason for this update (and if it's an official one).
> 
> apt-get -s update
> 
> Reading Package Lists...
> Building Dependency Tree...
> The following packages will be upgraded:
>   boxbackup-client boxbackup-server boxbackup-utils
> 3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Inst boxbackup-client [0.09-2] (0.09-3 debian.myreseau.org)
> Inst boxbackup-server [0.09-2] (0.09-3 debian.myreseau.org)
> Inst boxbackup-utils [0.09-2] (0.09-3 debian.myreseau.org)
> Conf boxbackup-client (0.09-3 debian.myreseau.org)
> Conf boxbackup-server (0.09-3 debian.myreseau.org)
> Conf boxbackup-utils (0.09-3 debian.myreseau.org)
> 

Nothing very important, just minor packaging modifications and man pages 
addition for some client side commands.

Regards
-- 
J?r?me


From boxbackup at fluffy.co.uk  Thu Oct 13 20:01:49 2005
From: boxbackup at fluffy.co.uk (Alex Howansky)
Date: Thu, 13 Oct 2005 14:01:49 -0500 (CDT)
Subject: [Box Backup] confused about warning message
Message-ID: <Pine.LNX.4.58.0510131152470.31939@net-srv-0001.bvrd.com>

I'm getting these emails from one of my backup clients:

> The store account for <client-hostname> is full.
>
> =============================
> FILES ARE NOT BEING BACKED UP
> =============================
>
> Please adjust the limits on account 6 on server <server-hostname>.

Running "bbackupquery usage" on the client machine gives me this:

>          Used     4309.8Mb  95% **************************************
>     Old files     1427.9Mb  31% ************
> Deleted files     1705.2Mb  37% ***************
>   Directories       12.8Mb   0%
>    Soft limit     4096.0Mb  90% ************************************
>    Hard limit     4505.0Mb 100% ****************************************

I don't understand why I'm getting these warnings. Shouldn't deleted and old
files automatically be purged to make room for new ones?

The client log shows:

> Beginning scan of local files
> Opening connection to server <server-hostname>...
> Connection made, login successful
> Exceeded storage limits on server -- not uploading changes to files
> About to notify administrator about event store-full, running script '/usr/local/etc/box/bbackupd/NotifySysadmin.sh store-full'
> Finished scan of local files
> File statistics: total file size uploaded 0, bytes already on server 0, encoded size 0

-- 
Alex Howansky
Wankwood Associates
http://wankwood.com/


From boxbackup at fluffy.co.uk  Thu Oct 13 20:08:24 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Thu, 13 Oct 2005 20:08:24 +0100
Subject: [Box Backup] confused about warning message
In-Reply-To: <Pine.LNX.4.58.0510131152470.31939@net-srv-0001.bvrd.com>
References: <Pine.LNX.4.58.0510131152470.31939@net-srv-0001.bvrd.com>
Message-ID: <23EC2E2B-617D-473E-8288-29B020B52A9F@fluffy.co.uk>

On 13 Oct 2005, at 20:01, Alex Howansky wrote:

>
> I'm getting these emails from one of my backup clients:
>
>
>> The store account for <client-hostname> is full.
>>
>> =============================
>> FILES ARE NOT BEING BACKED UP
>> =============================
>>
>> Please adjust the limits on account 6 on server <server-hostname>.
>>
>
> Running "bbackupquery usage" on the client machine gives me this:
>
>
>>          Used     4309.8Mb  95%  
>> **************************************
>>     Old files     1427.9Mb  31% ************
>> Deleted files     1705.2Mb  37% ***************
>>   Directories       12.8Mb   0%
>>    Soft limit     4096.0Mb  90% ************************************
>>    Hard limit     4505.0Mb 100%  
>> ****************************************
>>
>
> I don't understand why I'm getting these warnings. Shouldn't  
> deleted and old
> files automatically be purged to make room for new ones?

It could be that your client is trying to upload more than 200Mb of  
data, which takes it over the limit during the session --  
housekeeping doesn't work when the store is being written to. Or  
there aren't enough old and delete files to be deleted to take it  
below the limit.

Ben






From boxbackup at fluffy.co.uk  Thu Oct 13 21:38:52 2005
From: boxbackup at fluffy.co.uk (Stefan Norlin)
Date: Thu, 13 Oct 2005 22:38:52 +0200
Subject: [Box Backup] Portability and public source depot
Message-ID: <011101c5d036$1fa055e0$0301050a@stenorhem>

Hi,

we have been using BoxBackup for a while. It works fine on Linux
boxes.

However, we would like to improve portability a bit. Both between
different Linux boxes of different versions and to other OS:s as well.
We are using AIX, FreeBSD, Linux, SCO OpenServer and Sun Solaris.

There seems to be numerous changes (including Solaris port) since
last release and I have seen discussions about a public depot for the
source code and therefore it seems any effort put in should be done
on as current code as possible.

Any updates on the source code depot?
Any comments regarding a portability effort?

We are also using the Windows client by Nick Knight and are working
on an improved installer to avoid having to edit config files by hand
after installation.

Regards,
Stefan


From boxbackup at fluffy.co.uk  Thu Oct 13 21:43:51 2005
From: boxbackup at fluffy.co.uk (Kai)
Date: Fri, 14 Oct 2005 09:43:51 +1300
Subject: [Box Backup] Portability and public source depot
In-Reply-To: <011101c5d036$1fa055e0$0301050a@stenorhem>
Message-ID: <E1EQ9vw-0002lU-00@grunt9.ihug.co.nz>

This sounds like a fine Idea to me, I'd be very interested in your Windows
port as I am currently rolling out box backup for friends and family and my
linux buddies are having no problem with it but People like my poor mother
(tm) aren't really having much luck with the windows client. 

I think with really good cross platform support box backup could seriously
take off.

> -----Original Message-----
> From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
> On Behalf Of Stefan Norlin
> Sent: Friday, October 14, 2005 9:39 AM
> To: boxbackup at fluffy.co.uk
> Subject: [Box Backup] Portability and public source depot
> 
> Hi,
> 
> we have been using BoxBackup for a while. It works fine on Linux
> boxes.
> 
> However, we would like to improve portability a bit. Both between
> different Linux boxes of different versions and to other OS:s as well.
> We are using AIX, FreeBSD, Linux, SCO OpenServer and Sun Solaris.
> 
> There seems to be numerous changes (including Solaris port) since
> last release and I have seen discussions about a public depot for the
> source code and therefore it seems any effort put in should be done
> on as current code as possible.
> 
> Any updates on the source code depot?
> Any comments regarding a portability effort?
> 
> We are also using the Windows client by Nick Knight and are working
> on an improved installer to avoid having to edit config files by hand
> after installation.
> 
> Regards,
> Stefan
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Thu Oct 13 21:47:17 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Thu, 13 Oct 2005 21:47:17 +0100
Subject: [Box Backup] Portability and public source depot
In-Reply-To: <011101c5d036$1fa055e0$0301050a@stenorhem>
References: <011101c5d036$1fa055e0$0301050a@stenorhem>
Message-ID: <13E6396C-7E3D-4026-B5CB-167EF1A4C5BC@fluffy.co.uk>

I am aware that I have not done anything about this. Which I suppose  
is part of the problem we're trying to solve. I will try and set some  
time aside to get this done in the next few days.

My apologies.

I think we're going to have to go for an SVN repository. Seems to be  
the one which will get most developers working on the project.

Ben


On 13 Oct 2005, at 21:38, Stefan Norlin wrote:

> Hi,
>
> we have been using BoxBackup for a while. It works fine on Linux
> boxes.
>
> However, we would like to improve portability a bit. Both between
> different Linux boxes of different versions and to other OS:s as well.
> We are using AIX, FreeBSD, Linux, SCO OpenServer and Sun Solaris.
>
> There seems to be numerous changes (including Solaris port) since
> last release and I have seen discussions about a public depot for the
> source code and therefore it seems any effort put in should be done
> on as current code as possible.
>
> Any updates on the source code depot?
> Any comments regarding a portability effort?
>
> We are also using the Windows client by Nick Knight and are working
> on an improved installer to avoid having to edit config files by hand
> after installation.
>
> Regards,
> Stefan
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>



From boxbackup at fluffy.co.uk  Thu Oct 13 21:55:22 2005
From: boxbackup at fluffy.co.uk (Stefan Norlin)
Date: Thu, 13 Oct 2005 22:55:22 +0200
Subject: [Box Backup] Portability and public source depot
References: <011101c5d036$1fa055e0$0301050a@stenorhem> <13E6396C-7E3D-4026-B5CB-167EF1A4C5BC@fluffy.co.uk>
Message-ID: <013801c5d038$6d5e26c0$0301050a@stenorhem>

> I think we're going to have to go for an SVN repository. Seems to be  
> the one which will get most developers working on the project.

Sounds fine.

Would have needed to have a Perforce depot hosted we would
gladly have helped out with that.

We use Perforce extensively ourselves...

Stefan



From boxbackup at fluffy.co.uk  Thu Oct 13 22:18:32 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Thu, 13 Oct 2005 22:18:32 +0100
Subject: [Box Backup] Portability and public source depot
In-Reply-To: <013801c5d038$6d5e26c0$0301050a@stenorhem>
References: <011101c5d036$1fa055e0$0301050a@stenorhem> <13E6396C-7E3D-4026-B5CB-167EF1A4C5BC@fluffy.co.uk> <013801c5d038$6d5e26c0$0301050a@stenorhem>
Message-ID: <210D9308-F0C4-4997-AB0B-3971F044236F@fluffy.co.uk>

On 13 Oct 2005, at 21:55, Stefan Norlin wrote:

>> I think we're going to have to go for an SVN repository. Seems to  
>> be  the one which will get most developers working on the project.
>>
>
> Sounds fine.
>
> Would have needed to have a Perforce depot hosted we would
> gladly have helped out with that.
>
> We use Perforce extensively ourselves...

As nice as the merging support would be to the way we plan to run  
things (as one branch per developer, merging in later), there's not  
much point if noone will use it.

Even if open source projects get free licenses.

Ben




From boxbackup at fluffy.co.uk  Thu Oct 13 22:32:11 2005
From: boxbackup at fluffy.co.uk (boxbackup at fluffy.co.uk)
Date: Fri, 14 Oct 2005 07:32:11 +1000
Subject: [Box Backup] Portability and public source depot
In-Reply-To: <210D9308-F0C4-4997-AB0B-3971F044236F@fluffy.co.uk>
Message-ID: <001801c5d03d$95307310$6501a8c0@SCOTTLAPTOP>

If you would like some assistance with free hosting etc. 
Let me know and I can provide some bandwidth/Server space.

Thank you
Scott McNee



-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] On
Behalf Of Ben Summers
Sent: Friday, 14 October 2005 7:19 AM
To: boxbackup at fluffy.co.uk
Subject: Re: [Box Backup] Portability and public source depot



On 13 Oct 2005, at 21:55, Stefan Norlin wrote:

>> I think we're going to have to go for an SVN repository. Seems to
>> be  the one which will get most developers working on the project.
>>
>
> Sounds fine.
>
> Would have needed to have a Perforce depot hosted we would
> gladly have helped out with that.
>
> We use Perforce extensively ourselves...

As nice as the merging support would be to the way we plan to run  
things (as one branch per developer, merging in later), there's not  
much point if noone will use it.

Even if open source projects get free licenses.

Ben


_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Thu Oct 13 22:39:18 2005
From: boxbackup at fluffy.co.uk (Charles Lecklider)
Date: Thu, 13 Oct 2005 22:39:18 +0100
Subject: [Box Backup] Portability and public source depot
In-Reply-To: <210D9308-F0C4-4997-AB0B-3971F044236F@fluffy.co.uk>
References: <011101c5d036$1fa055e0$0301050a@stenorhem> <13E6396C-7E3D-4026-B5CB-167EF1A4C5BC@fluffy.co.uk> <013801c5d038$6d5e26c0$0301050a@stenorhem> <210D9308-F0C4-4997-AB0B-3971F044236F@fluffy.co.uk>
Message-ID: <434ED406.3080908@invis.net>

Ben Summers wrote:
> As nice as the merging support would be to the way we plan to run 
> things (as one branch per developer, merging in later), there's not 
> much point if noone will use it.

I only saw one person object to Perforce in the previous thread. Were
there a whole load offlist, or was that it?

If you're happy that Perforce is the right solution technically it seems
daft to use something else because of one person. Of course, if there
were lots of others too then....

-C



From boxbackup at fluffy.co.uk  Thu Oct 13 22:50:19 2005
From: boxbackup at fluffy.co.uk (Kai)
Date: Fri, 14 Oct 2005 10:50:19 +1300
Subject: [Box Backup] Portability and public source depot
In-Reply-To: <001801c5d03d$95307310$6501a8c0@SCOTTLAPTOP>
Message-ID: <E1EQAyH-0004m3-00@grunt8.ihug.co.nz>

Ditto here for mirrors if needed. 

> -----Original Message-----
> From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
> On Behalf Of scott at lubetech.com.au
> Sent: Friday, October 14, 2005 10:32 AM
> To: boxbackup at fluffy.co.uk
> Subject: RE: [Box Backup] Portability and public source depot
> 
> 
> If you would like some assistance with free hosting etc.
> Let me know and I can provide some bandwidth/Server space.
> 
> Thank you
> Scott McNee
> 
> 
> 
> -----Original Message-----
> From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
> On
> Behalf Of Ben Summers
> Sent: Friday, 14 October 2005 7:19 AM
> To: boxbackup at fluffy.co.uk
> Subject: Re: [Box Backup] Portability and public source depot
> 
> 
> 
> On 13 Oct 2005, at 21:55, Stefan Norlin wrote:
> 
> >> I think we're going to have to go for an SVN repository. Seems to
> >> be  the one which will get most developers working on the project.
> >>
> >
> > Sounds fine.
> >
> > Would have needed to have a Perforce depot hosted we would
> > gladly have helped out with that.
> >
> > We use Perforce extensively ourselves...
> 
> As nice as the merging support would be to the way we plan to run
> things (as one branch per developer, merging in later), there's not
> much point if noone will use it.
> 
> Even if open source projects get free licenses.
> 
> Ben
> 
> 
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
> 
> 
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Thu Oct 13 22:57:55 2005
From: boxbackup at fluffy.co.uk (Stefan Norlin)
Date: Thu, 13 Oct 2005 23:57:55 +0200
Subject: [Box Backup] Portability and public source depot
References: <011101c5d036$1fa055e0$0301050a@stenorhem> <13E6396C-7E3D-4026-B5CB-167EF1A4C5BC@fluffy.co.uk> <013801c5d038$6d5e26c0$0301050a@stenorhem> <210D9308-F0C4-4997-AB0B-3971F044236F@fluffy.co.uk> <434ED406.3080908@invis.net>
Message-ID: <019101c5d041$5bc620d0$0301050a@stenorhem>

>> As nice as the merging support would be to the way we plan to run 
>> things (as one branch per developer, merging in later), there's not 
>> much point if noone will use it.
> 
> I only saw one person object to Perforce in the previous thread. Were
> there a whole load offlist, or was that it?
> 
> If you're happy that Perforce is the right solution technically it seems
> daft to use something else because of one person. Of course, if there
> were lots of others too then....

The main question is probably whether Ben would feel comfortable
using it... otherwise it will probably never get done. I could set up a
Perforce depot, publically available, right now if only someone has any
relevant files to check in to it. :)

Also I would be happy to help out would there be any administrative
tasks needed to be taken care of. We also have a few cgi scripts so
that files and changes can be browsed in a "comfortable" way.

I would basically do anything(?) just to be able to get going and start
making some changes here and there to impove the portability of the
otherwise really nice Box Backup application.

(Do I sound desperate or what?!)

Stefan



From boxbackup at fluffy.co.uk  Thu Oct 13 23:11:02 2005
From: boxbackup at fluffy.co.uk (John Pybus)
Date: Thu, 13 Oct 2005 23:11:02 +0100
Subject: [Box Backup] Portability and public source depot
In-Reply-To: <434ED406.3080908@invis.net>
References: <011101c5d036$1fa055e0$0301050a@stenorhem> <13E6396C-7E3D-4026-B5CB-167EF1A4C5BC@fluffy.co.uk> <013801c5d038$6d5e26c0$0301050a@stenorhem> <210D9308-F0C4-4997-AB0B-3971F044236F@fluffy.co.uk> <434ED406.3080908@invis.net>
Message-ID: <434EDB76.4040709@pybus.org>

Charles Lecklider wrote:
> Ben Summers wrote:
> 
>>As nice as the merging support would be to the way we plan to run 
>>things (as one branch per developer, merging in later), there's not 
>>much point if noone will use it.
> 
> I only saw one person object to Perforce in the previous thread. Were
> there a whole load offlist, or was that it?
> 
> If you're happy that Perforce is the right solution technically it seems
> daft to use something else because of one person. Of course, if there
> were lots of others too then....

I broadly echo the view of Martin Ebourne who did post to the list.  I 
would be more likely to contribute to a project using SVN.  If I did 
contribute to BoxBackup hosted in Perforce it would be with patches 
rather than installing the p4 client.

Subversion now comes packaged with the majority of Linux distributions, 
and has wider usage amongst OSS contributers.  So, unless it is unable 
to meet the needs of what is currently a fairly small project, I think 
it would be preferable, but at the end of the day getting _any_ 
community going and contributing to the code is what's important.

John


From boxbackup at fluffy.co.uk  Fri Oct 14 10:54:11 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Fri, 14 Oct 2005 10:54:11 +0100
Subject: [Box Backup] SVN repository up and running
Message-ID: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk>

I've just installed SVN and imported my latest Box Backup sources,  
which are essentially 0.09 plus a few tweeks, including the gcc4  
stuff. The repository is at

    http://bbdev.fluffy.co.uk/svn/

and the current version is at

    http://bbdev.fluffy.co.uk/svn/box/trunk

hopefully following usual SVN conventions. The repository does not  
require a password for read only access.


I would like developers to copy the trunk to a working directory

    http://bbdev.fluffy.co.uk/svn/box/USERNAME/TASKNAME

and then work there, and once everyone is happy, merge back into  
trunk. No direct commits to trunk, please.

Before you start work on anything, please email me. I will coordinate  
the tasks. At this stage we have to pull in lots of work, it's  
important to try and get an order of merging which causes least  
issues. I think we'll try for smaller changes first.

We may need a boxbackup-dev mailing list shortly.


---------------------------------------
BIG IMPORTANT NOTE: All the files in the distribution have the  
license as the first page or so. None of the files in the repository  
do -- they're added by the makedistribution.pl script. Please do not  
accidently add the license when you copy in your work.

Also, I would ask that people match the style of coding (see previous  
discussion on the list). I will back out any change which doesn't  
meet it, just to avoid getting everything in a mess.
---------------------------------------


My time is a bit limited at the moment, but I promise I will attend  
to all relevant tasks in a timely manner. I hope others will make it  
easy for me to do so.


A few requests:

Developers: Please email me off-list with your preferred username,  
and I'll set you up an account.

SVN experts: Could someone post some working guidelines to the list,  
including all the weird and wacky SVN commands we'd need to run? (I'm  
especially interested in how to review changes then merge them into  
truck.)

Finally, I would like to backup the repository to two other places. I  
suspect rsync is probably the best tool for the job, given the  
incremental file adding nature of fsfs SVN repositories. Can I take  
up a couple of the offers of server space?


Sorry this has taken so long.

Ben





From boxbackup at fluffy.co.uk  Fri Oct 14 11:13:42 2005
From: boxbackup at fluffy.co.uk (Garry Glendown)
Date: Fri, 14 Oct 2005 12:13:42 +0200
Subject: [Box Backup] SVN repository up and running
In-Reply-To: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk>
References: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk>
Message-ID: <434F84D6.2030708@nethinks.com>

> Finally, I would like to backup the repository to two other places. I  
> suspect rsync is probably the best tool for the job, given the  
> incremental file adding nature of fsfs SVN repositories. Can I take  up 
> a couple of the offers of server space?

Why not via BoxBackup? ;)

Either way, *Sticking up hand* let me know if you need either web or 
bb-space .. ;)

-garry


From boxbackup at fluffy.co.uk  Fri Oct 14 11:17:55 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Fri, 14 Oct 2005 11:17:55 +0100
Subject: [Box Backup] SVN repository up and running
In-Reply-To: <434F84D6.2030708@nethinks.com>
References: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk> <434F84D6.2030708@nethinks.com>
Message-ID: <09EC17DA-BFAE-4860-B607-FF21D631E7F8@fluffy.co.uk>

On 14 Oct 2005, at 11:13, Garry Glendown wrote:


>> Finally, I would like to backup the repository to two other  
>> places. I  suspect rsync is probably the best tool for the job,  
>> given the  incremental file adding nature of fsfs SVN  
>> repositories. Can I take  up a couple of the offers of server space?
>>
>>
>
> Why not via BoxBackup? ;)
>

Because it's the wrong tool for the job?


>
> Either way, *Sticking up hand* let me know if you need either web  
> or bb-space .. ;)
>

Thanks. I shall collect the offers and choose the best two. :-)

Ben







From boxbackup at fluffy.co.uk  Fri Oct 14 11:21:27 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Fri, 14 Oct 2005 11:21:27 +0100
Subject: [Box Backup] SVN repository up and running
In-Reply-To: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk>
References: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk>
Message-ID: <20051014112127.9cj8yh9sissco40s@ebourne.me.uk>

Ben Summers <ben at fluffy.co.uk> wrote:
> Finally, I would like to backup the repository to two other places. I 
>  suspect rsync is probably the best tool for the job, given the  
> incremental file adding nature of fsfs SVN repositories. Can I take  
> up a couple of the offers of server space?

I find box backup works very well for this. :)

Cheers,

Martin.


From boxbackup at fluffy.co.uk  Fri Oct 14 12:03:14 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Fri, 14 Oct 2005 12:03:14 +0100
Subject: [Box Backup] SVN repository up and running
In-Reply-To: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk>
References: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk>
Message-ID: <20051014120314.0e9fuv905c008gsw@ebourne.me.uk>

Ben Summers <ben at fluffy.co.uk> wrote:
> SVN experts: Could someone post some working guidelines to the list,  
> including all the weird and wacky SVN commands we'd need to run? (I'm 
>  especially interested in how to review changes then merge them into  
> truck.)

Just for starters.

Here's a simple tutorial. The local repository stuff isn't relevant but 
the rest is. It doesn't cover branching (or rather it does because 
branching is exactly the same as tagging in svn, but it doesn't tell 
you that nor explain why).

   http://artis.imag.fr/Membres/Xavier.Decoret/resources/svn/

Here is the official SVN user guide book. Contains everything you need 
to know. Worth skimming through or dipping in, unless you've got time 
to read the whole thing of course!

   http://svnbook.red-bean.com/

That site is not responding for me at the moment, which is surely a 
temporary problem, always worked before. Here's a mirror I've found:

   http://support.informatik.uni-freiburg.de/manuals/subversion/index.html

FAQ:

   http://subversion.tigris.org/faq.html

SVN home page:

   http://subversion.tigris.org/

I'll come up with something a bit more box specific soon.

Cheers,

Martin.


From boxbackup at fluffy.co.uk  Fri Oct 14 15:40:07 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Fri, 14 Oct 2005 15:40:07 +0100
Subject: [Box Backup] SVN repository up and running
In-Reply-To: <20051014120314.0e9fuv905c008gsw@ebourne.me.uk>
References: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk>
 <20051014120314.0e9fuv905c008gsw@ebourne.me.uk>
Message-ID: <20051014154007.jmhgs02u8kcw4wo0@ebourne.me.uk>

Martin Ebourne <lists at ebourne.me.uk> wrote:
> Ben Summers <ben at fluffy.co.uk> wrote:
>> SVN experts: Could someone post some working guidelines to the list, 
>>  including all the weird and wacky SVN commands we'd need to run? 
>> (I'm  especially interested in how to review changes then merge them 
>> into  truck.)
>
> I'll come up with something a bit more box specific soon.

Well I said it'd be a bit more specific, and it sure is.

I've created the following branches with my respective patches in them:

martin/solaris
martin/ppcfixes
martin/xattr
martin/autoconf

Ideally I'd like to merge them in that order as & when. Hopefully the 
solaris patch can go in asap because it's been around for a long time. 
The ppcfixes and xattr patches are fairly localised and should be ok.

autoconf is very invasive and will need some thinking about.

All my changes should already meet all of Ben's style criteria. If 
anyone wants to code review them then please go for it. They've all 
been tested (not since I've added them as branches, but the rejects 
were minor so should be ok).

I've included below a complete annotated transcript of everything I did 
to make the branches and check my patches in. There's also some merging 
in there towards the end. It's very long due to the file lists, but 
it's pretty simple so hopefully someone will find it helpful to follow.

One thing to note, I've repeatedly checked my changes in as small units 
as I went. This isn't necessary, but I've found it works better that 
way when you later want to diff/merge/revert/whatever.

Cheers,

Martin.

First need to check out the repository to work with.

    % svn co http://bbdev.fluffy.co.uk/svn/box/ svn
    A    svn/trunk
    <...trimmed...>
    A    svn/trunk/runtest.pl
    Checked out revision 1.

Make myself a subdirectory as Ben requested.

    % cd svn
    % mkdir martin
    % svn add martin
    A         martin

Branch the trunk for my first patch.

    % svn cp trunk martin/ppcfixes
    A         martin/ppcfixes
    % svn ci -m "Branched martin/ppcfixes from trunk"
    Authentication realm: <http://bbdev.fluffy.co.uk:80> Box Backup dev
    Password for 'martin':
    Adding         martin
    Adding         martin/ppcfixes
    Committed revision 2.

Apply the patch in the branch. I had to resolve a minor reject.

    % cd martin/ppcfixes
    % patch -p0 < ../../../ppcfixes.patch
    patching file test/common/testcommon.cpp
    Hunk #1 succeeded at 139 (offset -39 lines).
    patching file infrastructure/BoxPlatform.pm
    Hunk #1 FAILED at 69.
    1 out of 1 hunk FAILED -- saving rejects to file 
infrastructure/BoxPlatform.pm.rej
    patching file lib/backupclient/BackupStoreFile.cpp
    Hunk #1 succeeded at 929 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFile.h
    Hunk #1 succeeded at 124 (offset -37 lines).
    patching file lib/common/DebugMemLeakFinder.cpp
    Hunk #1 succeeded at 216 (offset -39 lines).
    % em infrastructure/BoxPlatform.pm
    % svn st
    ?      test/common/testcommon.cpp.orig
    M      test/common/testcommon.cpp
    ?      infrastructure/BoxPlatform.pm.orig
    ?      lib/backupclient/BackupStoreFile.cpp.orig
    ?      lib/backupclient/BackupStoreFile.h.orig
    M      lib/backupclient/BackupStoreFile.cpp
    M      lib/backupclient/BackupStoreFile.h
    ?      lib/common/DebugMemLeakFinder.cpp.orig
    M      lib/common/DebugMemLeakFinder.cpp
    % svn ci -m "Applied ppcfixes patch to martin/ppcfixes"
    Sending        ppcfixes/lib/backupclient/BackupStoreFile.cpp
    Sending        ppcfixes/lib/backupclient/BackupStoreFile.h
    Sending        ppcfixes/lib/common/DebugMemLeakFinder.cpp
    Sending        ppcfixes/test/common/testcommon.cpp
    Transmitting file data ....
    Committed revision 3.

Make another branch for the next patch.

    % ..
    % ls
    ppcfixes/
    % svn cp ../trunk xattr
    A         xattr
    % svn ci -m "Branched martin/xattr from trunk"
    Adding         martin/xattr
    Committed revision 4.

And apply the patch to it.

    % cd xattr
    % patch -p0 < ../../../xattr.patch
    patching file infrastructure/tests/common_tests.pl
    Hunk #1 succeeded at 143 (offset -39 lines).
    patching file lib/backupclient/BackupClientFileAttributes.cpp
    Hunk #1 succeeded at 14 (offset -39 lines).
    Hunk #3 succeeded at 263 (offset -39 lines).
    Hunk #5 succeeded at 338 (offset -39 lines).
    Hunk #7 succeeded at 580 (offset -39 lines).
    Hunk #9 succeeded at 708 (offset 28 lines).
    Hunk #10 succeeded at 878 (offset -67 lines).
    Hunk #11 succeeded at 995 (offset 28 lines).
    patching file lib/backupclient/BackupClientFileAttributes.h
    Hunk #1 succeeded at 52 (offset -39 lines).
    patching file lib/common/DebugMemLeakFinder.cpp
    Hunk #1 succeeded at 93 (offset -39 lines).
    patching file lib/common/StreamableMemBlock.cpp
    Hunk #1 succeeded at 225 (offset -39 lines).
    patching file bin/bbackupd/BackupClientDirectoryRecord.cpp
    Hunk #1 succeeded at 154 (offset -39 lines).
    % svn ci -m "Applied xattr patch to martin/xattr"
    Sending        xattr/bin/bbackupd/BackupClientDirectoryRecord.cpp
    Sending        xattr/infrastructure/tests/common_tests.pl
    Sending        xattr/lib/backupclient/BackupClientFileAttributes.cpp
    Sending        xattr/lib/backupclient/BackupClientFileAttributes.h
    Sending        xattr/lib/common/DebugMemLeakFinder.cpp
    Sending        xattr/lib/common/StreamableMemBlock.cpp
    Transmitting file data ......
    Committed revision 5.

Make the third branch. In this case the autoconf patch comes after the xattr
patch and will not apply without it. Hence I branch here from my xattr branch,
rather than the trunk.

    % ..
    % svn cp xattr autoconf
    A         autoconf
    % svn ci -m "Branched martin/autoconf from martin/xattr"
    Adding         martin/autoconf
    Adding         martin/autoconf/bin/bbackupd/BackupClientDirectoryRecord.cpp
    Adding         martin/autoconf/infrastructure/tests/common_tests.pl
    Adding         
martin/autoconf/lib/backupclient/BackupClientFileAttributes.cpp
    Adding         
martin/autoconf/lib/backupclient/BackupClientFileAttributes.h
    Adding         martin/autoconf/lib/common/DebugMemLeakFinder.cpp
    Adding         martin/autoconf/lib/common/StreamableMemBlock.cpp
    Committed revision 6.

Now I apply the patch. It's very invasive this one, as you can see.

    % ls
    autoconf/  ppcfixes/  xattr/
    % cd autoconf
    % patch -p0 < ../../../autoconf.patch    patching file configure
    Reversed (or previously applied) patch detected!  Assume -R? [n] n
    Apply anyway? [n] y
    Hunk #1 FAILED at 1.
    File configure is not empty after patch, as expected
    1 out of 1 hunk FAILED -- saving rejects to file configure.rej
    patching file test/raidfile/testraidfile.cpp
    Hunk #1 FAILED at 564.
    1 out of 1 hunk FAILED -- saving rejects to file 
test/raidfile/testraidfile.cpp.rej
    patching file test/raidfile/intercept.cpp
    Hunk #1 succeeded at 9 (offset -39 lines).
    Hunk #3 FAILED at 79.
    Hunk #4 succeeded at 144 (offset -39 lines).
    Hunk #6 succeeded at 184 (offset -39 lines).
    Hunk #8 succeeded at 223 (offset -39 lines).
    Hunk #9 FAILED at 240.
    2 out of 9 hunks FAILED -- saving rejects to file 
test/raidfile/intercept.cpp.rej
    patching file test/crypto/testcrypto.cpp
    Hunk #1 succeeded at 256 (offset -39 lines).
    patching file test/common/testcommon.cpp
    Hunk #1 FAILED at 435.
    Hunk #2 succeeded at 483 (offset -40 lines).
    1 out of 3 hunks FAILED -- saving rejects to file 
test/common/testcommon.cpp.rej
    patching file test/backupstorefix/testbackupstorefix.cpp
    Hunk #1 succeeded at 411 (offset -39 lines).
    patching file test/backupdiff/testbackupdiff.cpp
    Hunk #1 succeeded at 92 (offset -39 lines).
    Hunk #3 succeeded at 115 (offset -39 lines).
    patching file infrastructure/BoxPlatform.pm
    Reversed (or previously applied) patch detected!  Assume -R? [n] n
    Apply anyway? [n] y
    Hunk #1 FAILED at 1.
    File infrastructure/BoxPlatform.pm is not empty after patch, as expected
    1 out of 1 hunk FAILED -- saving rejects to file 
infrastructure/BoxPlatform.pm.rej
    patching file infrastructure/m4/ax_check_mount_point.m4
    patching file infrastructure/m4/ax_check_bdb_v1.m4
    patching file infrastructure/m4/ax_check_syscall_lseek.m4
    patching file infrastructure/m4/ac_cxx_namespaces.m4
    patching file infrastructure/m4/ax_check_nonaligned_access.m4
    patching file infrastructure/m4/ac_cxx_exceptions.m4
    patching file infrastructure/m4/ax_check_define_pragma.m4
    patching file infrastructure/m4/ax_check_ssl.m4
    patching file infrastructure/m4/ax_check_malloc_workaround.m4
    patching file infrastructure/m4/ax_random_device.m4
    patching file infrastructure/m4/ax_check_llong_minmax.m4
    patching file infrastructure/m4/vl_lib_readline.m4
    patching file infrastructure/m4/ax_func_syscall.m4
    patching file infrastructure/m4/ax_check_dirent_d_type.m4
    patching file infrastructure/makebuildenv.pl
    Hunk #1 succeeded at 12 (offset -39 lines).
    Hunk #2 FAILED at 21.
    Hunk #3 succeeded at 76 (offset 3 lines).
    Hunk #4 FAILED at 152.
    Hunk #5 FAILED at 502.
    Hunk #6 succeeded at 651 (offset -29 lines).
    Hunk #7 succeeded at 750 (offset 3 lines).
    Hunk #8 succeeded at 772 (offset -29 lines).
    3 out of 8 hunks FAILED -- saving rejects to file 
infrastructure/makebuildenv.pl.rej
    patching file infrastructure/BoxPlatform.pm.in
    patching file modules.txt
    Hunk #2 succeeded at 34 (offset 1 line).
    patching file configure.ac
    patching file lib/raidfile/RaidFileWrite.cpp
    Hunk #1 FAILED at 151.
    Hunk #2 FAILED at 162.
    Hunk #3 FAILED at 429.
    Hunk #4 FAILED at 503.
    Hunk #5 FAILED at 560.
    5 out of 5 hunks FAILED -- saving rejects to file 
lib/raidfile/RaidFileWrite.cpp.rej
    patching file lib/raidfile/RaidFileRead.cpp
    Hunk #1 succeeded at 29 (offset -39 lines).
    Hunk #2 succeeded at 754 (offset 4 lines).
    Hunk #3 succeeded at 1229 (offset -39 lines).
    Hunk #4 succeeded at 1337 (offset 4 lines).
    Hunk #5 succeeded at 1527 (offset -39 lines).
    Hunk #6 FAILED at 1539.
    Hunk #7 FAILED at 1549.
    Hunk #8 FAILED at 1577.
    3 out of 8 hunks FAILED -- saving rejects to file 
lib/raidfile/RaidFileRead.cpp.rej
    patching file lib/raidfile/RaidFileUtil.cpp
    Hunk #1 FAILED at 93.
    Hunk #2 FAILED at 110.
    Hunk #3 FAILED at 131.
    Hunk #4 FAILED at 140.
    4 out of 4 hunks FAILED -- saving rejects to file 
lib/raidfile/RaidFileUtil.cpp.rej
    patching file lib/crypto/CipherAES.cpp
    Hunk #1 succeeded at 10 (offset -39 lines).
    patching file lib/crypto/CipherBlowfish.cpp
    Hunk #1 succeeded at 11 (offset -39 lines).
    Hunk #3 succeeded at 66 (offset -39 lines).
    Hunk #5 succeeded at 110 (offset -39 lines).
    Hunk #7 succeeded at 196 (offset -39 lines).
    patching file lib/crypto/CipherAES.h
    Hunk #1 succeeded at 11 (offset -39 lines).
    patching file lib/crypto/CipherBlowfish.h
    Hunk #1 succeeded at 10 (offset -39 lines).
    patching file lib/crypto/CipherContext.cpp
    Hunk #1 succeeded at 29 (offset -39 lines).
    Hunk #3 succeeded at 83 (offset -39 lines).
    Hunk #5 succeeded at 137 (offset -39 lines).
    Hunk #7 succeeded at 285 (offset -39 lines).
    Hunk #9 succeeded at 472 (offset -39 lines).
    Hunk #11 succeeded at 578 (offset -39 lines).
    patching file lib/crypto/Random.cpp
    Hunk #1 succeeded at 28 (offset -39 lines).
    patching file lib/crypto/CipherDescription.h
    Hunk #1 succeeded at 47 (offset -39 lines).
    patching file lib/crypto/CipherContext.h
    Hunk #1 succeeded at 62 (offset -39 lines).
    patching file lib/backupstore/BackupStoreInfo.cpp
    Hunk #1 succeeded at 19 (offset -39 lines).
    Hunk #3 succeeded at 111 (offset -39 lines).
    Hunk #5 succeeded at 210 (offset -39 lines).
    Hunk #7 succeeded at 329 (offset -39 lines).
    patching file lib/backupstore/BackupStoreCheck2.cpp
    Hunk #1 succeeded at 377 (offset -39 lines).
    patching file lib/backupclient/BackupClientCryptoKeys.cpp
    Hunk #1 succeeded at 54 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileDiff.cpp
    Hunk #1 succeeded at 104 (offset -39 lines).
    Hunk #3 succeeded at 306 (offset -39 lines).
    Hunk #5 succeeded at 347 (offset -39 lines).
    patching file lib/backupclient/BackupClientFileAttributes.cpp
    Hunk #1 succeeded at 17 (offset -39 lines).
    Hunk #3 succeeded at 73 (offset -39 lines).
    Hunk #5 succeeded at 413 (offset -39 lines).
    Hunk #7 succeeded at 617 (offset -39 lines).
    Hunk #8 succeeded at 757 (offset 67 lines).
    patching file lib/backupclient/BackupStoreFileEncodeStream.cpp
    Hunk #1 succeeded at 178 (offset -39 lines).
    Hunk #3 succeeded at 338 (offset -39 lines).
    Hunk #5 succeeded at 580 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCombine.cpp
    Hunk #1 succeeded at 94 (offset -39 lines).
    Hunk #3 succeeded at 160 (offset -39 lines).
    Hunk #5 succeeded at 220 (offset -39 lines).
    Hunk #7 succeeded at 362 (offset -39 lines).
    Hunk #9 succeeded at 396 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCryptVar.h
    Hunk #1 succeeded at 22 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFile.cpp
    Hunk #1 succeeded at 154 (offset -39 lines).
    Hunk #3 succeeded at 201 (offset -39 lines).
    Hunk #5 succeeded at 245 (offset -39 lines).
    Hunk #7 succeeded at 508 (offset -39 lines).
    Hunk #9 succeeded at 587 (offset -39 lines).
    Hunk #11 succeeded at 697 (offset -39 lines).
    Hunk #13 succeeded at 1036 (offset -39 lines).
    Hunk #15 succeeded at 1277 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCmbDiff.cpp
    Hunk #1 succeeded at 63 (offset -39 lines).
    Hunk #3 succeeded at 106 (offset -39 lines).
    Hunk #5 succeeded at 177 (offset -39 lines).
    Hunk #7 succeeded at 292 (offset -39 lines).
    patching file lib/backupclient/BackupStoreObjectDump.cpp
    Hunk #1 succeeded at 152 (offset -39 lines).
    Hunk #3 succeeded at 193 (offset -39 lines).
    patching file lib/backupclient/BackupStoreDirectory.cpp
    Hunk #1 succeeded at 19 (offset -39 lines).
    Hunk #3 succeeded at 135 (offset -39 lines).
    Hunk #5 succeeded at 480 (offset -39 lines).
    Hunk #7 succeeded at 536 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCmbIdx.cpp
    Hunk #1 succeeded at 156 (offset -39 lines).
    Hunk #3 succeeded at 190 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCryptVar.cpp
    Hunk #1 succeeded at 17 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileWire.h
    Hunk #1 succeeded at 13 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFile.h
    Hunk #1 succeeded at 113 (offset -37 lines).
    patching file lib/backupclient/BackupStoreFilename.h
    Hunk #1 succeeded at 30 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileRevDiff.cpp
    Hunk #1 succeeded at 59 (offset -39 lines).
    Hunk #3 succeeded at 106 (offset -39 lines).
    Hunk #5 succeeded at 153 (offset -39 lines).
    Hunk #7 succeeded at 225 (offset -39 lines).
    patching file lib/server/Protocol.cpp
    Hunk #1 FAILED at 462.
    Hunk #2 FAILED at 486.
    Hunk #3 FAILED at 597.
    Hunk #4 FAILED at 621.
    4 out of 4 hunks FAILED -- saving rejects to file 
lib/server/Protocol.cpp.rej
    patching file lib/server/Daemon.cpp
    Hunk #1 succeeded at 512 (offset -47 lines).
    patching file lib/server/SocketStream.cpp
    Hunk #1 succeeded at 372 (offset -39 lines).
    Hunk #3 succeeded at 394 (offset -39 lines).
    patching file lib/server/SocketListen.h
    Hunk #1 succeeded at 16 (offset -39 lines).
    patching file lib/server/SSLLib.cpp
    Hunk #1 succeeded at 45 (offset -39 lines).
    patching file lib/server/Socket.cpp
    Hunk #1 succeeded at 49 (offset -39 lines).
    patching file lib/server/ProtocolWire.h
    Hunk #1 succeeded at 13 (offset -39 lines).
    patching file lib/common/LinuxWorkaround.h
    Reversed (or previously applied) patch detected!  Assume -R? [n] n
    Apply anyway? [n] y
    Hunk #1 FAILED at 1.
    File lib/common/LinuxWorkaround.h is not empty after patch, as expected
    1 out of 1 hunk FAILED -- saving rejects to file 
lib/common/LinuxWorkaround.h.rej
    patching file lib/common/LinuxWorkaround.cpp
    Reversed (or previously applied) patch detected!  Assume -R? [n] n  
   Apply anyway? [n] y
    Hunk #1 FAILED at 1.
    File lib/common/LinuxWorkaround.cpp is not empty after patch, as expected
    1 out of 1 hunk FAILED -- saving rejects to file 
lib/common/LinuxWorkaround.cpp.rej
    patching file lib/common/BoxPlatform.h
    Hunk #1 FAILED at 55.
    1 out of 1 hunk FAILED -- saving rejects to file 
lib/common/BoxPlatform.h.rej
    patching file lib/common/EventWatchFilesystemObject.cpp
    Hunk #1 succeeded at 27 (offset -39 lines).
    patching file lib/common/TemporaryDirectory.h
    Hunk #1 succeeded at 12 (offset -39 lines).
    patching file lib/common/WaitForEvent.h
    Hunk #1 succeeded at 10 (offset -39 lines).
    Hunk #3 succeeded at 63 (offset -39 lines).
    Hunk #5 succeeded at 128 (offset -39 lines).
    patching file lib/common/ExcludeList.h
    Hunk #1 succeeded at 45 (offset -39 lines).
    patching file lib/common/Box.h
    Hunk #1 succeeded at 21 (offset -34 lines).
    Hunk #2 succeeded at 161 (offset -1 lines).
    patching file lib/common/EventWatchFilesystemObject.h
    Hunk #1 succeeded at 10 (offset -39 lines).
    patching file lib/common/EndStructPackForWire.h
    Hunk #1 succeeded at 9 (offset -39 lines).
    patching file lib/common/WaitForEvent.cpp
    Hunk #1 succeeded at 25 (offset -39 lines).
    Hunk #3 succeeded at 79 (offset -39 lines).
    patching file lib/common/ExcludeList.cpp
    Hunk #1 succeeded at 9 (offset -39 lines).
    Hunk #3 succeeded at 106 (offset -39 lines).
    patching file lib/common/FileModificationTime.h
    Hunk #1 succeeded at 16 (offset -39 lines).
    Hunk #3 succeeded at 40 (offset -39 lines).
    patching file lib/common/BeginStructPackForWire.h
    Hunk #1 succeeded at 9 (offset -39 lines).
    patching file lib/common/NamedLock.cpp
    Hunk #1 FAILED at 51.
    Hunk #2 FAILED at 107.
    Hunk #3 succeeded at 111 (offset -57 lines).
    2 out of 3 hunks FAILED -- saving rejects to file 
lib/common/NamedLock.cpp.rej
    patching file bin/bbackupd/BackupClientInodeToIDMap.cpp
    Hunk #1 succeeded at 9 (offset -39 lines).
    patching file bin/bbackupd/BackupClientInodeToIDMap.h
    Hunk #1 succeeded at 16 (offset -39 lines).
    patching file bin/bbackupd/BackupClientDirectoryRecord.cpp
    Hunk #1 succeeded at 26 (offset -39 lines).
    patching file bin/bbackupd/BackupDaemon.cpp
    Hunk #1 FAILED at 51.
    Hunk #2 succeeded at 890 (offset -44 lines).
    Hunk #3 FAILED at 953.
    Hunk #4 succeeded at 1041 (offset -30 lines).
    Hunk #5 succeeded at 1049 (offset -44 lines).
    Hunk #6 succeeded at 1099 (offset -30 lines).
    2 out of 6 hunks FAILED -- saving rejects to file 
bin/bbackupd/BackupDaemon.cpp.rej
    patching file bin/bbackupquery/BackupQueries.cpp
    Hunk #1 succeeded at 1163 (offset -39 lines).
    patching file bin/bbackupquery/bbackupquery.cpp
    Hunk #1 succeeded at 12 (offset -39 lines).
    Hunk #3 succeeded at 211 (offset -39 lines).
    patching file bootstrap

I start to resolve the rejects.

    % svn rm configure
    D         configure
    % em test/raidfile/testraidfile.cpp

At this point I realise that Ben hasn't applied the solaris patch to 
trunk yet. The autoconf patch comes after the solaris patch and needs 
that too. I need to backtrack all of this autoconf branch out and start 
again differently.

    % ..
    % ls
    autoconf/  ppcfixes/  xattr/
    % svn revert --recursive autoconf
    Reverted 'autoconf/test/raidfile/intercept.cpp'
    Reverted 'autoconf/test/crypto/testcrypto.cpp'
    <...trimmed...>
    Reverted 'autoconf/bin/bbackupquery/BackupQueries.cpp'
    Reverted 'autoconf/bin/bbackupquery/bbackupquery.cpp'
    % rm -rf autoconf
    % svn rm autoconf
    D         autoconf
    % svn ci -m "Removed martin/autoconf, forgot to apply solaris patch first"
    Deleting       martin/autoconf
    Committed revision 7.

Make another branch from trunk for the solaris patch.

    % svn cp ../trunk solaris
    A         solaris
    % svn ci -m "Branched martin/solaris from trunk"
    Adding         martin/solaris
    Committed revision 8.

Apply the solaris patch and fix the reject.

    % cd solaris
    % patch -p0 < ../../../solaris.patch
    patching file test/raidfile/testraidfile.cpp
    Hunk #1 succeeded at 525 (offset -39 lines).
    patching file test/raidfile/intercept.cpp
    Hunk #1 succeeded at 34 (offset -39 lines).
    Hunk #3 succeeded at 97 (offset -39 lines).
    patching file test/backupstore/testbackupstore.cpp
    Hunk #1 succeeded at 584 (offset -39 lines).
    Hunk #3 succeeded at 637 (offset -39 lines).
    Hunk #5 succeeded at 1732 (offset -39 lines).
    patching file test/common/testcommon.cpp
    Hunk #1 succeeded at 397 (offset -39 lines).
    patching file infrastructure/makebuildenv.pl
    Hunk #1 succeeded at 758 (offset -26 lines).
    Hunk #3 succeeded at 960 (offset -26 lines).
    patching file infrastructure/makeparcels.pl
    Hunk #1 succeeded at 99 (offset -39 lines).
    patching file infrastructure/BoxPlatform.pm
    Hunk #1 FAILED at 40.
    Hunk #2 succeeded at 9 (offset -39 lines).
    Hunk #3 succeeded at 106 (offset 3 lines).
    1 out of 3 hunks FAILED -- saving rejects to file 
infrastructure/BoxPlatform.pm.rej
    patching file lib/raidfile/RaidFileWrite.cpp
    Hunk #1 succeeded at 112 (offset -39 lines).
    Hunk #3 succeeded at 459 (offset -39 lines).
    patching file lib/raidfile/RaidFileRead.cpp
    Hunk #1 succeeded at 317 (offset -39 lines).
    Hunk #3 succeeded at 1585 (offset -39 lines).
    patching file lib/raidfile/RaidFileUtil.cpp
    Hunk #1 succeeded at 54 (offset -39 lines).
    Hunk #3 succeeded at 92 (offset -39 lines).
    patching file lib/server/Protocol.cpp
    Hunk #1 succeeded at 423 (offset -39 lines).
    Hunk #3 succeeded at 558 (offset -39 lines).
    patching file lib/server/Daemon.cpp
    Hunk #1 succeeded at 141 (offset -39 lines).
    patching file lib/server/SocketStreamTLS.cpp
    Hunk #1 succeeded at 14 (offset -39 lines).
    patching file lib/common/BoxPlatform.h
    Hunk #1 succeeded at 133 (offset -36 lines).
    Hunk #3 succeeded at 189 (offset -36 lines).
    patching file lib/common/NamedLock.cpp
    Hunk #1 succeeded at 12 (offset -39 lines).
    Hunk #3 succeeded at 88 (offset -39 lines).
    patching file bin/bbackupd/BackupDaemon.cpp
    Hunk #1 succeeded at 15 (offset -39 lines).
    Hunk #3 succeeded at 1018 (offset -39 lines).
    % em infrastructure/BoxPlatform.pm
    % svn ci -m "Applied solaris patch to martin/solaris"
    Sending        solaris/bin/bbackupd/BackupDaemon.cpp
    Sending        solaris/infrastructure/BoxPlatform.pm
    Sending        solaris/infrastructure/makebuildenv.pl
    Sending        solaris/infrastructure/makeparcels.pl
    Sending        solaris/lib/common/BoxPlatform.h
    Sending        solaris/lib/common/NamedLock.cpp
    Sending        solaris/lib/raidfile/RaidFileRead.cpp
    Sending        solaris/lib/raidfile/RaidFileUtil.cpp
    Sending        solaris/lib/raidfile/RaidFileWrite.cpp
    Sending        solaris/lib/server/Daemon.cpp
    Sending        solaris/lib/server/Protocol.cpp
    Sending        solaris/lib/server/SocketStreamTLS.cpp
    Sending        solaris/test/backupstore/testbackupstore.cpp
    Sending        solaris/test/common/testcommon.cpp
    Sending        solaris/test/raidfile/intercept.cpp
    Sending        solaris/test/raidfile/testraidfile.cpp
    Transmitting file data ................
    Committed revision 9.

Now I remake the autoconf branch. This time I take it from the solaris branch.

    % ..
    % svn cp solaris autoconf
    A         autoconf
    % svn ci -m "Branched martin/autoconf from martin/solaris"
    Adding         martin/autoconf
    Adding         martin/autoconf/bin/bbackupd/BackupDaemon.cpp
    Adding         martin/autoconf/infrastructure/BoxPlatform.pm
    Adding         martin/autoconf/infrastructure/makebuildenv.pl
    Adding         martin/autoconf/infrastructure/makeparcels.pl
    Adding         martin/autoconf/lib/common/BoxPlatform.h
    Adding         martin/autoconf/lib/common/NamedLock.cpp
    Adding         martin/autoconf/lib/raidfile/RaidFileRead.cpp
    Adding         martin/autoconf/lib/raidfile/RaidFileUtil.cpp
    Adding         martin/autoconf/lib/raidfile/RaidFileWrite.cpp
    Adding         martin/autoconf/lib/server/Daemon.cpp
    Adding         martin/autoconf/lib/server/Protocol.cpp
    Adding         martin/autoconf/lib/server/SocketStreamTLS.cpp
    Adding         martin/autoconf/test/backupstore/testbackupstore.cpp
    Adding         martin/autoconf/test/common/testcommon.cpp
    Adding         martin/autoconf/test/raidfile/intercept.cpp
    Adding         martin/autoconf/test/raidfile/testraidfile.cpp
    Committed revision 10.

As I said before, the autoconf patch also needs the xattr patch before it will
apply, so now I need to merge the xattr commit into the autoconf branch. First
I look to see what versions need merging.

    % svn log
    ------------------------------------------------------------------------
    r2 | martin | 2005-10-14 11:37:29 +0100 (Fri, 14 Oct 2005) | 1 line

    Branched martin/ppcfixes from trunk
    ------------------------------------------------------------------------

As you can see, the log has all the changes I've made missing. Not to fear,
this is a little oddity with svn which can catch you out, though it does make
sense if you read the book. :)

Briefly, although I've committed new changes to the repository, I've not
updated my working copy to the latest version and so I've got a working copy
with files at different versions in it. The best plan is just to update, then
it will all work fine.

    % svn up
    At revision 10.
    % svn log
    ------------------------------------------------------------------------
    r10 | martin | 2005-10-14 12:11:17 +0100 (Fri, 14 Oct 2005) | 1 line

    Branched martin/autoconf from martin/solaris
    ------------------------------------------------------------------------
    r9 | martin | 2005-10-14 12:10:41 +0100 (Fri, 14 Oct 2005) | 1 line

    Applied solaris patch to martin/solaris
    ------------------------------------------------------------------------
    r8 | martin | 2005-10-14 12:06:46 +0100 (Fri, 14 Oct 2005) | 1 line

    Branched martin/solaris from trunk
    ------------------------------------------------------------------------
    r7 | martin | 2005-10-14 12:03:01 +0100 (Fri, 14 Oct 2005) | 1 line

    Removed martin/autoconf, forgot to apply solaris patch first
    ------------------------------------------------------------------------
    r6 | martin | 2005-10-14 11:56:30 +0100 (Fri, 14 Oct 2005) | 1 line

    Branched martin/autoconf from martin/xattr
    ------------------------------------------------------------------------
    r5 | martin | 2005-10-14 11:45:01 +0100 (Fri, 14 Oct 2005) | 1 line

    Applied xattr patch to martin/xattr
    ------------------------------------------------------------------------
    r4 | martin | 2005-10-14 11:43:18 +0100 (Fri, 14 Oct 2005) | 1 line

    Branched martin/xattr from trunk
    ------------------------------------------------------------------------
    r3 | martin | 2005-10-14 11:42:37 +0100 (Fri, 14 Oct 2005) | 1 line

    Applied ppcfixes patch to martin/ppcfixes
    ------------------------------------------------------------------------
    r2 | martin | 2005-10-14 11:37:29 +0100 (Fri, 14 Oct 2005) | 1 line

    Branched martin/ppcfixes from trunk
    ------------------------------------------------------------------------

 From that I can see that the xattr changes are in revision 5 (or with an
alternative reading, they are the difference between revisions 4 and 5). Thus
merging the changes from the xattr branch onto the autoconf branch is easy:

    % svn merge -r 4:5 xattr autoconf
    U    autoconf/infrastructure/tests/common_tests.pl
    U    autoconf/lib/backupclient/BackupClientFileAttributes.cpp
    U    autoconf/lib/backupclient/BackupClientFileAttributes.h
    U    autoconf/lib/common/DebugMemLeakFinder.cpp
    U    autoconf/lib/common/StreamableMemBlock.cpp
    U    autoconf/bin/bbackupd/BackupClientDirectoryRecord.cpp

Currently svn doesn't record merging in the metadata. The best bet therefore
is to be consistent about recording merges in the change history.

    % svn ci -m "Merged r4:5 from martin/xattr to martin/autoconf.
    dquote> This is the xattr patch, which is required because autoconf 
was done later."
    Sending        martin/autoconf/bin/bbackupd/BackupClientDirectoryRecord.cpp
    Sending        martin/autoconf/infrastructure/tests/common_tests.pl
    Sending        
martin/autoconf/lib/backupclient/BackupClientFileAttributes.cpp
    Sending        
martin/autoconf/lib/backupclient/BackupClientFileAttributes.h
    Sending        martin/autoconf/lib/common/DebugMemLeakFinder.cpp
    Sending        martin/autoconf/lib/common/StreamableMemBlock.cpp
    Transmitting file data ......
    Committed revision 11.

Now I reapply the autoconf patch and get less rejects this time.

    % cd autoconf
    % patch -p0 < ../../../autoconf.patch
    patching file configure
    Reversed (or previously applied) patch detected!  Assume -R? [n] n
    Apply anyway? [n] y
    Hunk #1 FAILED at 1.
    File configure is not empty after patch, as expected
    1 out of 1 hunk FAILED -- saving rejects to file configure.rej
    patching file test/raidfile/testraidfile.cpp
    Hunk #1 succeeded at 525 (offset -39 lines).
    patching file test/raidfile/intercept.cpp
    Hunk #1 succeeded at 9 (offset -39 lines).
    Hunk #3 succeeded at 40 (offset -39 lines).
    Hunk #5 succeeded at 165 (offset -39 lines).
    Hunk #7 succeeded at 200 (offset -39 lines).
    Hunk #9 succeeded at 240 (offset -39 lines).
    patching file test/crypto/testcrypto.cpp
    Hunk #1 succeeded at 256 (offset -39 lines).
    patching file test/common/testcommon.cpp
    Hunk #1 succeeded at 397 (offset -38 lines).
    Hunk #3 succeeded at 500 (offset -38 lines).
    patching file test/backupstorefix/testbackupstorefix.cpp
    Hunk #1 succeeded at 411 (offset -39 lines).
    patching file test/backupdiff/testbackupdiff.cpp
    Hunk #1 succeeded at 92 (offset -39 lines).
    Hunk #3 succeeded at 115 (offset -39 lines).
    patching file infrastructure/BoxPlatform.pm
    Reversed (or previously applied) patch detected!  Assume -R? [n] n
    Apply anyway? [n] y
    Hunk #1 FAILED at 1.
    File infrastructure/BoxPlatform.pm is not empty after patch, as expected
    1 out of 1 hunk FAILED -- saving rejects to file 
infrastructure/BoxPlatform.pm.rej
    patching file infrastructure/m4/ax_check_mount_point.m4
    patching file infrastructure/m4/ax_check_bdb_v1.m4
    patching file infrastructure/m4/ax_check_syscall_lseek.m4
    patching file infrastructure/m4/ac_cxx_namespaces.m4
    patching file infrastructure/m4/ax_check_nonaligned_access.m4
    patching file infrastructure/m4/ac_cxx_exceptions.m4
    patching file infrastructure/m4/ax_check_define_pragma.m4
    patching file infrastructure/m4/ax_check_ssl.m4
    patching file infrastructure/m4/ax_check_malloc_workaround.m4
    patching file infrastructure/m4/ax_random_device.m4
    patching file infrastructure/m4/ax_check_llong_minmax.m4
    patching file infrastructure/m4/vl_lib_readline.m4
    patching file infrastructure/m4/ax_func_syscall.m4
    patching file infrastructure/m4/ax_check_dirent_d_type.m4
    patching file infrastructure/makebuildenv.pl
    Hunk #1 succeeded at 12 (offset -39 lines).
    Hunk #2 FAILED at 21.
    Hunk #3 succeeded at 76 (offset 3 lines).
    Hunk #4 FAILED at 152.
    Hunk #5 succeeded at 470 (offset -29 lines).
    Hunk #6 succeeded at 683 (offset 3 lines).
    Hunk #7 succeeded at 718 (offset -29 lines).
    Hunk #8 succeeded at 804 (offset 3 lines).
    2 out of 8 hunks FAILED -- saving rejects to file 
infrastructure/makebuildenv.pl.rej
    patching file infrastructure/BoxPlatform.pm.in
    patching file modules.txt
    Hunk #2 succeeded at 34 (offset 1 line).
    patching file configure.ac
    patching file lib/raidfile/RaidFileWrite.cpp
    Hunk #1 succeeded at 112 (offset -39 lines).
    Hunk #3 succeeded at 387 (offset -42 lines).
    Hunk #4 FAILED at 461.
    Hunk #5 succeeded at 559 (offset -1 lines).
    1 out of 5 hunks FAILED -- saving rejects to file 
lib/raidfile/RaidFileWrite.cpp.rej
    patching file lib/raidfile/RaidFileRead.cpp
    Hunk #1 succeeded at 29 (offset -39 lines).
    Hunk #3 succeeded at 1229 (offset -39 lines).
    Hunk #5 succeeded at 1527 (offset -39 lines).
    Hunk #7 succeeded at 1549 (offset -39 lines).
    patching file lib/raidfile/RaidFileUtil.cpp
    Hunk #1 succeeded at 54 (offset -39 lines).
    Hunk #3 succeeded at 92 (offset -39 lines).
    patching file lib/crypto/CipherAES.cpp
    Hunk #1 succeeded at 10 (offset -39 lines).
    patching file lib/crypto/CipherBlowfish.cpp
    Hunk #1 succeeded at 11 (offset -39 lines).
    Hunk #3 succeeded at 66 (offset -39 lines).
    Hunk #5 succeeded at 110 (offset -39 lines).
    Hunk #7 succeeded at 196 (offset -39 lines).
    patching file lib/crypto/CipherAES.h
    Hunk #1 succeeded at 11 (offset -39 lines).
    patching file lib/crypto/CipherBlowfish.h
    Hunk #1 succeeded at 10 (offset -39 lines).
    patching file lib/crypto/CipherContext.cpp
    Hunk #1 succeeded at 29 (offset -39 lines).
    Hunk #3 succeeded at 83 (offset -39 lines).
    Hunk #5 succeeded at 137 (offset -39 lines).
    Hunk #7 succeeded at 285 (offset -39 lines).
    Hunk #9 succeeded at 472 (offset -39 lines).
    Hunk #11 succeeded at 578 (offset -39 lines).
    patching file lib/crypto/Random.cpp
    Hunk #1 succeeded at 28 (offset -39 lines).
    patching file lib/crypto/CipherDescription.h
    Hunk #1 succeeded at 47 (offset -39 lines).
    patching file lib/crypto/CipherContext.h
    Hunk #1 succeeded at 62 (offset -39 lines).
    patching file lib/backupstore/BackupStoreInfo.cpp
    Hunk #1 succeeded at 19 (offset -39 lines).
    Hunk #3 succeeded at 111 (offset -39 lines).
    Hunk #5 succeeded at 210 (offset -39 lines).
    Hunk #7 succeeded at 329 (offset -39 lines).
    patching file lib/backupstore/BackupStoreCheck2.cpp
    Hunk #1 succeeded at 377 (offset -39 lines).
    patching file lib/backupclient/BackupClientCryptoKeys.cpp
    Hunk #1 succeeded at 54 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileDiff.cpp
    Hunk #1 succeeded at 104 (offset -39 lines).
    Hunk #3 succeeded at 306 (offset -39 lines).
    Hunk #5 succeeded at 347 (offset -39 lines).
    patching file lib/backupclient/BackupClientFileAttributes.cpp
    Hunk #1 succeeded at 17 (offset -39 lines).
    Hunk #3 succeeded at 73 (offset -39 lines).
    Hunk #5 succeeded at 413 (offset -39 lines).
    Hunk #7 succeeded at 617 (offset -39 lines).
    Hunk #8 succeeded at 757 (offset 67 lines).
    patching file lib/backupclient/BackupStoreFileEncodeStream.cpp
    Hunk #1 succeeded at 178 (offset -39 lines).
    Hunk #3 succeeded at 338 (offset -39 lines).
    Hunk #5 succeeded at 580 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCombine.cpp
    Hunk #1 succeeded at 94 (offset -39 lines).
    Hunk #3 succeeded at 160 (offset -39 lines).
    Hunk #5 succeeded at 220 (offset -39 lines).
    Hunk #7 succeeded at 362 (offset -39 lines).
    Hunk #9 succeeded at 396 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCryptVar.h
    Hunk #1 succeeded at 22 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFile.cpp
    Hunk #1 succeeded at 154 (offset -39 lines).
    Hunk #3 succeeded at 201 (offset -39 lines).
    Hunk #5 succeeded at 245 (offset -39 lines).
    Hunk #7 succeeded at 508 (offset -39 lines).
    Hunk #9 succeeded at 587 (offset -39 lines).
    Hunk #11 succeeded at 697 (offset -39 lines).
    Hunk #13 succeeded at 1036 (offset -39 lines).
    Hunk #15 succeeded at 1277 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCmbDiff.cpp
    Hunk #1 succeeded at 63 (offset -39 lines).
    Hunk #3 succeeded at 106 (offset -39 lines).
    Hunk #5 succeeded at 177 (offset -39 lines).
    Hunk #7 succeeded at 292 (offset -39 lines).
    patching file lib/backupclient/BackupStoreObjectDump.cpp
    Hunk #1 succeeded at 152 (offset -39 lines).
    Hunk #3 succeeded at 193 (offset -39 lines).
    patching file lib/backupclient/BackupStoreDirectory.cpp
    Hunk #1 succeeded at 19 (offset -39 lines).
    Hunk #3 succeeded at 135 (offset -39 lines).
    Hunk #5 succeeded at 480 (offset -39 lines).
    Hunk #7 succeeded at 536 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCmbIdx.cpp
    Hunk #1 succeeded at 156 (offset -39 lines).
    Hunk #3 succeeded at 190 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileCryptVar.cpp
    Hunk #1 succeeded at 17 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileWire.h
    Hunk #1 succeeded at 13 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFile.h
    Hunk #1 succeeded at 113 (offset -37 lines).
    patching file lib/backupclient/BackupStoreFilename.h
    Hunk #1 succeeded at 30 (offset -39 lines).
    patching file lib/backupclient/BackupStoreFileRevDiff.cpp
    Hunk #1 succeeded at 59 (offset -39 lines).
    Hunk #3 succeeded at 106 (offset -39 lines).
    Hunk #5 succeeded at 153 (offset -39 lines).
    Hunk #7 succeeded at 225 (offset -39 lines).
    patching file lib/server/Protocol.cpp
    Hunk #1 succeeded at 423 (offset -39 lines).
    Hunk #3 succeeded at 558 (offset -39 lines).
    patching file lib/server/Daemon.cpp
    Hunk #1 succeeded at 520 (offset -39 lines).
    patching file lib/server/SocketStream.cpp
    Hunk #1 succeeded at 372 (offset -39 lines).
    Hunk #3 succeeded at 394 (offset -39 lines).
    patching file lib/server/SocketListen.h
    Hunk #1 succeeded at 16 (offset -39 lines).
    patching file lib/server/SSLLib.cpp
    Hunk #1 succeeded at 45 (offset -39 lines).
    patching file lib/server/Socket.cpp
    Hunk #1 succeeded at 49 (offset -39 lines).
    patching file lib/server/ProtocolWire.h
    Hunk #1 succeeded at 13 (offset -39 lines).
    patching file lib/common/LinuxWorkaround.h
    Reversed (or previously applied) patch detected!  Assume -R? [n] n
    Apply anyway? [n] y
    Hunk #1 FAILED at 1.
    File lib/common/LinuxWorkaround.h is not empty after patch, as expected
    1 out of 1 hunk FAILED -- saving rejects to file 
lib/common/LinuxWorkaround.h.rej
    patching file lib/common/LinuxWorkaround.cpp
    Reversed (or previously applied) patch detected!  Assume -R? [n] n
    Apply anyway? [n] y
    Hunk #1 FAILED at 1.
    File lib/common/LinuxWorkaround.cpp is not empty after patch, as expected
    1 out of 1 hunk FAILED -- saving rejects to file 
lib/common/LinuxWorkaround.cpp.rej
    patching file lib/common/BoxPlatform.h
    Hunk #1 FAILED at 55.
    1 out of 1 hunk FAILED -- saving rejects to file 
lib/common/BoxPlatform.h.rej
    patching file lib/common/EventWatchFilesystemObject.cpp
    Hunk #1 succeeded at 27 (offset -39 lines).
    patching file lib/common/TemporaryDirectory.h
    Hunk #1 succeeded at 12 (offset -39 lines).
    patching file lib/common/WaitForEvent.h
    Hunk #1 succeeded at 10 (offset -39 lines).
    Hunk #3 succeeded at 63 (offset -39 lines).
    Hunk #5 succeeded at 128 (offset -39 lines).
    patching file lib/common/ExcludeList.h
    Hunk #1 succeeded at 45 (offset -39 lines).
    patching file lib/common/Box.h
    Hunk #1 succeeded at 21 (offset -34 lines).
    Hunk #2 succeeded at 161 (offset -1 lines).
    patching file lib/common/EventWatchFilesystemObject.h
    Hunk #1 succeeded at 10 (offset -39 lines).
    patching file lib/common/EndStructPackForWire.h
    Hunk #1 succeeded at 9 (offset -39 lines).
    patching file lib/common/WaitForEvent.cpp
    Hunk #1 succeeded at 25 (offset -39 lines).
    Hunk #3 succeeded at 79 (offset -39 lines).
    patching file lib/common/ExcludeList.cpp
    Hunk #1 succeeded at 9 (offset -39 lines).
    Hunk #3 succeeded at 106 (offset -39 lines).
    patching file lib/common/FileModificationTime.h
    Hunk #1 succeeded at 16 (offset -39 lines).
    Hunk #3 succeeded at 40 (offset -39 lines).
    patching file lib/common/BeginStructPackForWire.h
    Hunk #1 succeeded at 9 (offset -39 lines).
    patching file lib/common/NamedLock.cpp
    Hunk #1 succeeded at 12 (offset -39 lines).
    Hunk #3 succeeded at 129 (offset -39 lines).
    patching file bin/bbackupd/BackupClientInodeToIDMap.cpp
    Hunk #1 succeeded at 9 (offset -39 lines).
    patching file bin/bbackupd/BackupClientInodeToIDMap.h
    Hunk #1 succeeded at 16 (offset -39 lines).
    patching file bin/bbackupd/BackupClientDirectoryRecord.cpp
    Hunk #1 succeeded at 26 (offset -39 lines).
    patching file bin/bbackupd/BackupDaemon.cpp
    Hunk #1 succeeded at 12 (offset -39 lines).
    Hunk #3 succeeded at 958 (offset -39 lines).
    Hunk #5 succeeded at 1054 (offset -39 lines).
    patching file bin/bbackupquery/BackupQueries.cpp
    Hunk #1 succeeded at 1163 (offset -39 lines).
    patching file bin/bbackupquery/bbackupquery.cpp
    Hunk #1 succeeded at 12 (offset -39 lines).
    Hunk #3 succeeded at 211 (offset -39 lines).
    patching file bootstrap

Resolving the rejects. Most were deleted files which hadn't matched, so just
need an 'svn rm'. BoxPlatform.h has been rewritten and rejected whole, so the
easist solution there was to copy the new file over and apply the tweaks to
that.

    % svn rm configure
    D         configure
    % svn rm infrastructure/BoxPlatform.pm
    D         infrastructure/BoxPlatform.pm
    % em infrastructure/makebuildenv.pl
    % em lib/raidfile/RaidFileWrite.cpp
    % svn rm lib/common/LinuxWorkaround.h lib/common/LinuxWorkaround.cpp
    D         lib/common/LinuxWorkaround.h
    D         lib/common/LinuxWorkaround.cpp
    % cp ../../../BoxPlatform.h lib/common
    % em lib/common/BoxPlatform.h

None of the other patches had new or removed files, so this step wasn't
needed. Now I check to see what files need to be added to/removed from the
repository. Remove all of patch's .orig files first to remove clutter.

    % rm -f **/*.orig
    % svn st
    ?      configure.ac
    ?      bootstrap
    M      test/raidfile/testraidfile.cpp
    M      test/raidfile/intercept.cpp
    M      test/crypto/testcrypto.cpp
    M      test/common/testcommon.cpp
    M      test/backupstorefix/testbackupstorefix.cpp
    M      test/backupdiff/testbackupdiff.cpp
    ?      infrastructure/m4
    ?      infrastructure/BoxPlatform.pm.in
    M      infrastructure/makebuildenv.pl
    D      infrastructure/BoxPlatform.pm
    D      configure
    M      lib/raidfile/RaidFileWrite.cpp
    M      lib/raidfile/RaidFileRead.cpp
    M      lib/raidfile/RaidFileUtil.cpp
    M      lib/crypto/CipherAES.cpp
    M      lib/crypto/CipherBlowfish.cpp
    M      lib/crypto/CipherAES.h
    M      lib/crypto/CipherBlowfish.h
    M      lib/crypto/CipherContext.cpp
    M      lib/crypto/Random.cpp
    M      lib/crypto/CipherDescription.h
    M      lib/crypto/CipherContext.h
    M      lib/backupstore/BackupStoreInfo.cpp
    M      lib/backupstore/BackupStoreCheck2.cpp
    M      lib/backupclient/BackupClientCryptoKeys.cpp
    M      lib/backupclient/BackupStoreFileDiff.cpp
    M      lib/backupclient/BackupClientFileAttributes.cpp
    M      lib/backupclient/BackupStoreFileEncodeStream.cpp
    M      lib/backupclient/BackupStoreFileCombine.cpp
    M      lib/backupclient/BackupStoreFileCryptVar.h
    M      lib/backupclient/BackupStoreFile.cpp
    M      lib/backupclient/BackupStoreFileCmbDiff.cpp
    M      lib/backupclient/BackupStoreObjectDump.cpp
    M      lib/backupclient/BackupStoreDirectory.cpp
    M      lib/backupclient/BackupStoreFileCmbIdx.cpp
    M      lib/backupclient/BackupStoreFileCryptVar.cpp
    M      lib/backupclient/BackupStoreFileWire.h
    M      lib/backupclient/BackupStoreFile.h
    M      lib/backupclient/BackupStoreFilename.h
    M      lib/backupclient/BackupStoreFileRevDiff.cpp
    M      lib/server/Protocol.cpp
    M      lib/server/Daemon.cpp
    M      lib/server/SocketStream.cpp
    M      lib/server/SocketListen.h
    M      lib/server/SSLLib.cpp
    M      lib/server/Socket.cpp
    M      lib/server/ProtocolWire.h
    M      lib/common/BoxPlatform.h
    M      lib/common/TemporaryDirectory.h
    M      lib/common/WaitForEvent.h
    M      lib/common/Box.h
    M      lib/common/WaitForEvent.cpp
    M      lib/common/EndStructPackForWire.h
    D      lib/common/LinuxWorkaround.h
    M      lib/common/NamedLock.cpp
    M      lib/common/EventWatchFilesystemObject.cpp
    D      lib/common/LinuxWorkaround.cpp
    M      lib/common/ExcludeList.h
    M      lib/common/EventWatchFilesystemObject.h
    M      lib/common/ExcludeList.cpp
    M      lib/common/FileModificationTime.h
    M      lib/common/BeginStructPackForWire.h
    M      modules.txt
    M      bin/bbackupd/BackupClientInodeToIDMap.cpp
    M      bin/bbackupd/BackupClientInodeToIDMap.h
    M      bin/bbackupd/BackupClientDirectoryRecord.cpp
    M      bin/bbackupd/BackupDaemon.cpp
    M      bin/bbackupquery/BackupQueries.cpp
    M      bin/bbackupquery/bbackupquery.cpp

The '?'s are things I need to look at. I've got a few new files, and one new
directory with files in. I can add the lot in one go and then checkin.

    % svn add configure.ac bootstrap infrastructure/m4 
infrastructure/BoxPlatform.pm.in
    A         configure.ac
    A         bootstrap
    A         infrastructure/m4
    A         infrastructure/m4/ac_cxx_exceptions.m4
    A         infrastructure/m4/ax_check_syscall_lseek.m4
    A         infrastructure/m4/ax_check_bdb_v1.m4
    A         infrastructure/m4/ax_check_malloc_workaround.m4
    A         infrastructure/m4/ax_check_llong_minmax.m4
    A         infrastructure/m4/ax_check_ssl.m4
    A         infrastructure/m4/ac_cxx_namespaces.m4
    A         infrastructure/m4/ax_check_mount_point.m4
    A         infrastructure/m4/ax_check_nonaligned_access.m4
    A         infrastructure/m4/ax_check_define_pragma.m4
    A         infrastructure/m4/vl_lib_readline.m4
    A         infrastructure/m4/ax_check_dirent_d_type.m4
    A         infrastructure/m4/ax_func_syscall.m4
    A         infrastructure/m4/ax_random_device.m4
    A         infrastructure/BoxPlatform.pm.in
    % svn ci -m "Applied autoconf patch to martin/autoconf    dquote> 
NB. This reverts out a change in BoxPlatform.h for missing socklen_t.   
   dquote> Remember to check if that needs an autoconf workaround or if 
it is ok now."
    Sending        autoconf/bin/bbackupd/BackupClientDirectoryRecord.cpp
    Sending        autoconf/bin/bbackupd/BackupClientInodeToIDMap.cpp
    <...trimmed...>
    Sending        autoconf/test/raidfile/intercept.cpp
    Sending        autoconf/test/raidfile/testraidfile.cpp
    Transmitting file data 
................................................................................
    Committed revision 12.

Check I've not missed anything and update ready for whatever's next.

    % ../..
    % l
    martin/  trunk/
    % rm -f **/*.orig
    % svn st
    % sv up
    zsh: correct 'sv' to 'svn' [nyae]? y
    At revision 12.
    %

Job done, tick.



From boxbackup at fluffy.co.uk  Fri Oct 14 16:05:22 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Fri, 14 Oct 2005 16:05:22 +0100
Subject: [Box Backup] SVN repository up and running
In-Reply-To: <20051014154007.jmhgs02u8kcw4wo0@ebourne.me.uk>
References: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk> <20051014120314.0e9fuv905c008gsw@ebourne.me.uk> <20051014154007.jmhgs02u8kcw4wo0@ebourne.me.uk>
Message-ID: <7BA5A825-6892-46B7-ABE0-0D7DD6861CDF@fluffy.co.uk>

On 14 Oct 2005, at 15:40, Martin Ebourne wrote:

> Martin Ebourne <lists at ebourne.me.uk> wrote:
>
>> Ben Summers <ben at fluffy.co.uk> wrote:
>>
>>> SVN experts: Could someone post some working guidelines to the  
>>> list,  including all the weird and wacky SVN commands we'd need  
>>> to run? (I'm  especially interested in how to review changes then  
>>> merge them into  truck.)
>>>
>>
>> I'll come up with something a bit more box specific soon.
>>
>
> Well I said it'd be a bit more specific, and it sure is.
>
> I've created the following branches with my respective patches in  
> them:
>
> martin/solaris
> martin/ppcfixes
> martin/xattr
> martin/autoconf
>
> Ideally I'd like to merge them in that order as & when. Hopefully  
> the solaris patch can go in asap because it's been around for a  
> long time. The ppcfixes and xattr patches are fairly localised and  
> should be ok.
>
> autoconf is very invasive and will need some thinking about.
>
> All my changes should already meet all of Ben's style criteria. If  
> anyone wants to code review them then please go for it. They've all  
> been tested (not since I've added them as branches, but the rejects  
> were minor so should be ok).

Is there a trivially easy way see what changes are made between trunk  
and, say, martin/solaris? Other than checking them out and running  
diff on them?

Ben







From boxbackup at fluffy.co.uk  Fri Oct 14 16:22:12 2005
From: boxbackup at fluffy.co.uk (Jonathan Morton)
Date: Fri, 14 Oct 2005 16:22:12 +0100
Subject: [Box Backup] SVN repository up and running
In-Reply-To: <7BA5A825-6892-46B7-ABE0-0D7DD6861CDF@fluffy.co.uk>
References: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk> <20051014120314.0e9fuv905c008gsw@ebourne.me.uk> <20051014154007.jmhgs02u8kcw4wo0@ebourne.me.uk> <7BA5A825-6892-46B7-ABE0-0D7DD6861CDF@fluffy.co.uk>
Message-ID: <e268ed53c7e7dd920b63a78f0eb7eb38@chromatix.uklinux.net>

>> All my changes should already meet all of Ben's style criteria. If 
>> anyone wants to code review them then please go for it. They've all 
>> been tested (not since I've added them as branches, but the rejects 
>> were minor so should be ok).
>
> Is there a trivially easy way see what changes are made between trunk 
> and, say, martin/solaris? Other than checking them out and running 
> diff on them?

The "svn diff" command should do that.  Haven't tried it yet, but the 
tutorial and manual that Martin linked says all about it.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi at chromatix.demon.co.uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.



From boxbackup at fluffy.co.uk  Fri Oct 14 16:24:04 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Fri, 14 Oct 2005 16:24:04 +0100
Subject: [Box Backup] SVN repository up and running
In-Reply-To: <7BA5A825-6892-46B7-ABE0-0D7DD6861CDF@fluffy.co.uk>
References: <6E74E328-187A-435E-B7C4-4917CAFA9B9B@fluffy.co.uk>
 <20051014120314.0e9fuv905c008gsw@ebourne.me.uk>
 <20051014154007.jmhgs02u8kcw4wo0@ebourne.me.uk>
 <7BA5A825-6892-46B7-ABE0-0D7DD6861CDF@fluffy.co.uk>
Message-ID: <20051014162404.f53jc0t4cg0c08wk@ebourne.me.uk>

Ben Summers <ben at fluffy.co.uk> wrote:
> Is there a trivially easy way see what changes are made between trunk 
>  and, say, martin/solaris? Other than checking them out and running  
> diff on them?

    svn diff http://bbdev.fluffy.co.uk/svn/box/trunk/ \
             http://bbdev.fluffy.co.uk/svn/box/martin/solaris/

This works straight from the repository with no checked out copy and is 
what you're after.

As to alternatives, the obvious approach from within a working copy is:

    svn diff trunk martin/solaris

but unfortunately this doesn't work - only diffs between revisions are 
implemented clientside at the moment. However, of course, diff works 
locally:

    diff -Nru --exclude .svn trunk martin/solaris

Alternatively in this case you could diff the changes between when the 
branch was taken and its head.

    svn diff -r 1:HEAD martin/solaris

Cheers,

Martin.


From boxbackup at fluffy.co.uk  Sat Oct 15 13:31:53 2005
From: boxbackup at fluffy.co.uk (Jonathan Morton)
Date: Sat, 15 Oct 2005 13:31:53 +0100
Subject: [Box Backup] Diff Optimisations now in SVN
Message-ID: <82b9cc3f81310a4e369c606fbfd860a3@chromatix.uklinux.net>

As of revision 17, a working version of my diff algorithm optimisations 
is in the tree (at chromi/diffopt).  It passes all tests on my G5 
(powerpc64-unknown-linux-gnu), except for raidfile, which seems to be 
completely broken on Linux/PPC anyway, and is unrelated to my changes.

Note that a side-effect of my using KATE is that there are a lot of 
deltas referring to blank lines, where KATE has deleted trailing 
whitespace characters from the entire file being edited.  I'm not sure 
what to do about that, aside from trying to work out the right GNU 
indent parameters and hoping nothing else breaks.  Perhaps someone had 
better go through all the other trees and delete trailing whitespace 
from them too.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi at chromatix.demon.co.uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.



From boxbackup at fluffy.co.uk  Mon Oct 17 14:59:39 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Mon, 17 Oct 2005 14:59:39 +0100
Subject: [Box Backup] Diff Optimisations now in SVN
In-Reply-To: <82b9cc3f81310a4e369c606fbfd860a3@chromatix.uklinux.net>
References: <82b9cc3f81310a4e369c606fbfd860a3@chromatix.uklinux.net>
Message-ID: <20051017145939.oz92zwvo8ck8w8cs@ebourne.me.uk>

Jonathan Morton <chromi at chromatix.uklinux.net> wrote:
> As of revision 17, a working version of my diff algorithm 
> optimisations is in the tree (at chromi/diffopt).  It passes all 
> tests on my G5 (powerpc64-unknown-linux-gnu), except for raidfile, 
> which seems to be completely broken on Linux/PPC anyway, and is 
> unrelated to my changes.

I've done a test merge of all my changes with your changes (just in my 
working copy, not checked in). It all merged without conflicts. I 
checked the merged files and they all looked sane.

It compiles and passes all the tests on i386-linux (though not first 
time - looks like bbstored processes aren't always exiting properly, 
causing subsequent tests to fail).

So pretty promising overall.

> Note that a side-effect of my using KATE is that there are a lot of 
> deltas referring to blank lines, where KATE has deleted trailing 
> whitespace characters from the entire file being edited.  I'm not 
> sure what to do about that, aside from trying to work out the right 
> GNU indent parameters and hoping nothing else breaks.  Perhaps 
> someone had better go through all the other trees and delete trailing 
> whitespace from them too.

I think the best thing to do here is 'diff -uw' your changes and apply 
that as a patch to a new copy from trunk. Otherwise this is going to 
cause excessive and unnecessary pain. That's exactly what I did for my 
merge above, and it worked well.

As to whether to strip trailing spaces, I prefer that. I have emacs set 
to do that by default, but I turn it off when working on box. KATE must 
have an option to turn it off too (I'd consider it a bug if not). But 
either way I don't much care.

If we did strip the spaces we should do it after the merges, not 
before, else it'll just cause even more pain.

Cheers,

Martin.



From boxbackup at fluffy.co.uk  Mon Oct 17 15:12:16 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Mon, 17 Oct 2005 15:12:16 +0100
Subject: [Box Backup] Source in SVN...
Message-ID: <D5EE299F-BC74-468F-B6E7-B7D5099C700E@fluffy.co.uk>

I think we're almost there with getting all the contributed code into  
the SVN repository. Just the win32 stuff to go, and then we'll be  
ready to start integrating everything.

Of course, we'll need some sort of review process before doing the  
final merges.

Ben





From boxbackup at fluffy.co.uk  Tue Oct 18 14:42:17 2005
From: boxbackup at fluffy.co.uk (Jonathan Morton)
Date: Tue, 18 Oct 2005 14:42:17 +0100
Subject: [Box Backup] Diff Optimisations now in SVN
In-Reply-To: <20051017145939.oz92zwvo8ck8w8cs@ebourne.me.uk>
References: <82b9cc3f81310a4e369c606fbfd860a3@chromatix.uklinux.net> <20051017145939.oz92zwvo8ck8w8cs@ebourne.me.uk>
Message-ID: <d06dc769a7984bfdc1bf7609156698c4@chromatix.uklinux.net>

>> Note that a side-effect of my using KATE is that there are a lot of 
>> deltas referring to blank lines, where KATE has deleted trailing 
>> whitespace characters from the entire file being edited.  I'm not 
>> sure what to do about that, aside from trying to work out the right 
>> GNU indent parameters and hoping nothing else breaks.  Perhaps 
>> someone had better go through all the other trees and delete trailing 
>> whitespace from them too.
>
> I think the best thing to do here is 'diff -uw' your changes and apply 
> that as a patch to a new copy from trunk. Otherwise this is going to 
> cause excessive and unnecessary pain. That's exactly what I did for my 
> merge above, and it worked well.

OK, I just did that (actually, made a plain patch against trunk 
alongside an --ignore-space-change version, reversed the plain one, 
then applied the other).  This seems to have corrected the problem 
cleanly, without affecting the existence blank lines in new code as -w 
would have.

> As to whether to strip trailing spaces, I prefer that. I have emacs 
> set to do that by default, but I turn it off when working on box. KATE 
> must have an option to turn it off too (I'd consider it a bug if not). 
> But either way I don't much care.

It does have the option, but there's no way to put the spaces back in 
after the fact, except by the above laborious patching method.  Since I 
greatly prefer to use KATE than other editors these days (Emacs is OK 
to use, but an utter pain to configure the way I like it), I think 
getting rid of the trailing spaces at *some* point is a good idea.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi at chromatix.demon.co.uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.



From boxbackup at fluffy.co.uk  Wed Oct 19 22:04:31 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Wed, 19 Oct 2005 22:04:31 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local>

Hello Stephan,

I would really be interested in your work on this...

Regards

Nick

-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
On Behalf Of Stefan Norlin
Sent: 13 October 2005 21:39
To: boxbackup at fluffy.co.uk
Subject: [unclassified] [Box Backup] Portability and public source depot

Hi,

we have been using BoxBackup for a while. It works fine on Linux
boxes.

However, we would like to improve portability a bit. Both between
different Linux boxes of different versions and to other OS:s as well.
We are using AIX, FreeBSD, Linux, SCO OpenServer and Sun Solaris.

There seems to be numerous changes (including Solaris port) since
last release and I have seen discussions about a public depot for the
source code and therefore it seems any effort put in should be done
on as current code as possible.

Any updates on the source code depot?
Any comments regarding a portability effort?

We are also using the Windows client by Nick Knight and are working
on an improved installer to avoid having to edit config files by hand
after installation.

Regards,
Stefan
_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Wed Oct 19 22:14:31 2005
From: boxbackup at fluffy.co.uk (Stefan Norlin)
Date: Wed, 19 Oct 2005 23:14:31 +0200
Subject: [unclassified] [Box Backup] Portability and public source depot
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local>
Message-ID: <003a01c5d4f2$18c73610$0301050a@stenorhem>

Hi Nick,

great. :)

We are currently "idling" a bit waiting for all bits and pieces
to drop in to the repository and being merged until we put to
much effort into making larger changes.

Regarding the Win client we have been using the source code
you made available some time ago in box0.09h.zip.

Are there newer versions of those files?
Are you planning (or have you already) created a branch in
the SVN repository for later merging?
Any other thoughts what needs to be done or some kind of
"todo" list for the Win client?
What is your current status and interest in developing it
further?

One thing we have though about would be the possibility
to use put configuration data into the registry as an
alternative to the configuration text file.

Stefan


----- Original Message ----- 
From: "Nick Knight" <nick at omniis.com>
To: <boxbackup at fluffy.co.uk>
Sent: Wednesday, October 19, 2005 11:04 PM
Subject: RE: [unclassified] [Box Backup] Portability and public source depot


> Hello Stephan,
>
> I would really be interested in your work on this...
>
> Regards
>
> Nick
>
> -----Original Message-----
> From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
> On Behalf Of Stefan Norlin
> Sent: 13 October 2005 21:39
> To: boxbackup at fluffy.co.uk
> Subject: [unclassified] [Box Backup] Portability and public source depot
>
> Hi,
>
> we have been using BoxBackup for a while. It works fine on Linux
> boxes.
>
> However, we would like to improve portability a bit. Both between
> different Linux boxes of different versions and to other OS:s as well.
> We are using AIX, FreeBSD, Linux, SCO OpenServer and Sun Solaris.
>
> There seems to be numerous changes (including Solaris port) since
> last release and I have seen discussions about a public depot for the
> source code and therefore it seems any effort put in should be done
> on as current code as possible.
>
> Any updates on the source code depot?
> Any comments regarding a portability effort?
>
> We are also using the Windows client by Nick Knight and are working
> on an improved installer to avoid having to edit config files by hand
> after installation.
>
> Regards,
> Stefan
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>
>
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
> 



From boxbackup at fluffy.co.uk  Wed Oct 19 22:18:25 2005
From: boxbackup at fluffy.co.uk (Kai)
Date: Thu, 20 Oct 2005 10:18:25 +1300
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <003a01c5d4f2$18c73610$0301050a@stenorhem>
Message-ID: <E1ESLKr-0004to-00@grunt6.ihug.co.nz>

The major gripe I've had from people about the win client is lack of a user
friendly GUI for config and restore. 

Which win client are you referring to here? The CMD line one or boxi? 

Just thinking if I might be able to contribute. 

> -----Original Message-----
> From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
> On Behalf Of Stefan Norlin
> Sent: Thursday, October 20, 2005 10:15 AM
> To: boxbackup at fluffy.co.uk
> Subject: Re: [unclassified] [Box Backup] Portability and public source
> depot
> 
> Hi Nick,
> 
> great. :)
> 
> We are currently "idling" a bit waiting for all bits and pieces
> to drop in to the repository and being merged until we put to
> much effort into making larger changes.
> 
> Regarding the Win client we have been using the source code
> you made available some time ago in box0.09h.zip.
> 
> Are there newer versions of those files?
> Are you planning (or have you already) created a branch in
> the SVN repository for later merging?
> Any other thoughts what needs to be done or some kind of
> "todo" list for the Win client?
> What is your current status and interest in developing it
> further?
> 
> One thing we have though about would be the possibility
> to use put configuration data into the registry as an
> alternative to the configuration text file.
> 
> Stefan
> 
> 
> ----- Original Message -----
> From: "Nick Knight" <nick at omniis.com>
> To: <boxbackup at fluffy.co.uk>
> Sent: Wednesday, October 19, 2005 11:04 PM
> Subject: RE: [unclassified] [Box Backup] Portability and public source
> depot
> 
> 
> > Hello Stephan,
> >
> > I would really be interested in your work on this...
> >
> > Regards
> >
> > Nick
> >
> > -----Original Message-----
> > From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
> > On Behalf Of Stefan Norlin
> > Sent: 13 October 2005 21:39
> > To: boxbackup at fluffy.co.uk
> > Subject: [unclassified] [Box Backup] Portability and public source depot
> >
> > Hi,
> >
> > we have been using BoxBackup for a while. It works fine on Linux
> > boxes.
> >
> > However, we would like to improve portability a bit. Both between
> > different Linux boxes of different versions and to other OS:s as well.
> > We are using AIX, FreeBSD, Linux, SCO OpenServer and Sun Solaris.
> >
> > There seems to be numerous changes (including Solaris port) since
> > last release and I have seen discussions about a public depot for the
> > source code and therefore it seems any effort put in should be done
> > on as current code as possible.
> >
> > Any updates on the source code depot?
> > Any comments regarding a portability effort?
> >
> > We are also using the Windows client by Nick Knight and are working
> > on an improved installer to avoid having to edit config files by hand
> > after installation.
> >
> > Regards,
> > Stefan
> > _______________________________________________
> > boxbackup mailing list
> > boxbackup at fluffy.co.uk
> > http://lists.warhead.org.uk/mailman/listinfo/boxbackup
> >
> >
> > _______________________________________________
> > boxbackup mailing list
> > boxbackup at fluffy.co.uk
> > http://lists.warhead.org.uk/mailman/listinfo/boxbackup
> >
> 
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Wed Oct 19 22:30:41 2005
From: boxbackup at fluffy.co.uk (Stefan Norlin)
Date: Wed, 19 Oct 2005 23:30:41 +0200
Subject: [unclassified] [Box Backup] Portability and public source depot
References: <E1ESLKr-0004to-00@grunt6.ihug.co.nz>
Message-ID: <004701c5d4f4$5b12e1c0$0301050a@stenorhem>

We are referring  to the command-line one. The Win port
of the "core" Box product.

I agree there is a need for a user interface in a longer perspective.
I have not looked at the boxi stuff yet, but that might be something
that is portable to Windows as well. It seems it runs under Cygwin
currently but claims to have the possibility of being cross platform.

As of now we are mainly interested in putting together a more
user-friendly installation with the possibility of entering config
parameters during the installation process. Then it would be
easy/easier to get it up and running on a Win box.

For restoring there are other alternatives for example via a simple
web-based UI or even a more manual approach.

>From our perspective:

Step 1, Being able to install the product easily and get files
backuped into the archive and having the possibility to restore
files even though it may be a bit tedious.

Step 2, Make the restore process more user-friendly as well.

Into which part would your potential contribution go?
The UI stuff?
If yes, maybe you could have a closer look at boxi and see what
it would take to get it up and running on a Windows box natively.

Stefan


----- Original Message ----- 
From: "Kai" <kai at kaos.gen.nz>
To: <boxbackup at fluffy.co.uk>
Sent: Wednesday, October 19, 2005 11:18 PM
Subject: RE: [unclassified] [Box Backup] Portability and public source depot


> The major gripe I've had from people about the win client is lack of a 
> user
> friendly GUI for config and restore.
>
> Which win client are you referring to here? The CMD line one or boxi?
>
> Just thinking if I might be able to contribute.
>
>> -----Original Message-----
>> From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
>> On Behalf Of Stefan Norlin
>> Sent: Thursday, October 20, 2005 10:15 AM
>> To: boxbackup at fluffy.co.uk
>> Subject: Re: [unclassified] [Box Backup] Portability and public source
>> depot
>>
>> Hi Nick,
>>
>> great. :)
>>
>> We are currently "idling" a bit waiting for all bits and pieces
>> to drop in to the repository and being merged until we put to
>> much effort into making larger changes.
>>
>> Regarding the Win client we have been using the source code
>> you made available some time ago in box0.09h.zip.
>>
>> Are there newer versions of those files?
>> Are you planning (or have you already) created a branch in
>> the SVN repository for later merging?
>> Any other thoughts what needs to be done or some kind of
>> "todo" list for the Win client?
>> What is your current status and interest in developing it
>> further?
>>
>> One thing we have though about would be the possibility
>> to use put configuration data into the registry as an
>> alternative to the configuration text file.
>>
>> Stefan
>>
>>
>> ----- Original Message -----
>> From: "Nick Knight" <nick at omniis.com>
>> To: <boxbackup at fluffy.co.uk>
>> Sent: Wednesday, October 19, 2005 11:04 PM
>> Subject: RE: [unclassified] [Box Backup] Portability and public source
>> depot
>>
>>
>> > Hello Stephan,
>> >
>> > I would really be interested in your work on this...
>> >
>> > Regards
>> >
>> > Nick
>> >
>> > -----Original Message-----
>> > From: boxbackup-admin at fluffy.co.uk 
>> > [mailto:boxbackup-admin at fluffy.co.uk]
>> > On Behalf Of Stefan Norlin
>> > Sent: 13 October 2005 21:39
>> > To: boxbackup at fluffy.co.uk
>> > Subject: [unclassified] [Box Backup] Portability and public source 
>> > depot
>> >
>> > Hi,
>> >
>> > we have been using BoxBackup for a while. It works fine on Linux
>> > boxes.
>> >
>> > However, we would like to improve portability a bit. Both between
>> > different Linux boxes of different versions and to other OS:s as well.
>> > We are using AIX, FreeBSD, Linux, SCO OpenServer and Sun Solaris.
>> >
>> > There seems to be numerous changes (including Solaris port) since
>> > last release and I have seen discussions about a public depot for the
>> > source code and therefore it seems any effort put in should be done
>> > on as current code as possible.
>> >
>> > Any updates on the source code depot?
>> > Any comments regarding a portability effort?
>> >
>> > We are also using the Windows client by Nick Knight and are working
>> > on an improved installer to avoid having to edit config files by hand
>> > after installation.
>> >
>> > Regards,
>> > Stefan
>> > _______________________________________________
>> > boxbackup mailing list
>> > boxbackup at fluffy.co.uk
>> > http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>> >
>> >
>> > _______________________________________________
>> > boxbackup mailing list
>> > boxbackup at fluffy.co.uk
>> > http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>> >
>>
>> _______________________________________________
>> boxbackup mailing list
>> boxbackup at fluffy.co.uk
>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>
>
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
> 



From boxbackup at fluffy.co.uk  Thu Oct 20 10:08:11 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Thu, 20 Oct 2005 10:08:11 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C573E@toutatis.omn11s.local>

Hello Stephan,

The h version is the latest - I have had no time lately to take it
further:( I will be putting it into Ben's SVN when I get time and my
head round it - hopefully within a week.

The TODO list is a little ad-hoc at the mo, briefly

1/ Stability, I know there are a couple of things which are problems
such as large files - corruption.

2/ Exchange capability, at the mo you have to backup exchange then
backup the backup file - this is not very efficient

3/ Perhaps system state - but I wouldn't even know where to start with
this!

4/ GUI

Registry or text file, I have had this discussion with Ben, he wants to
keep it consistent with all of the ports, which I can understand -
although it would be easier for a Windows programmer to write a front
end for the registry, it still can be done with the config file. I know
the gui which is floating around could be easily ported to use the
config file.

Nick

-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
On Behalf Of Stefan Norlin
Sent: 19 October 2005 22:15
To: boxbackup at fluffy.co.uk
Subject: Re: [unclassified] [Box Backup] Portability and public source
depot

Hi Nick,

great. :)

We are currently "idling" a bit waiting for all bits and pieces
to drop in to the repository and being merged until we put to
much effort into making larger changes.

Regarding the Win client we have been using the source code
you made available some time ago in box0.09h.zip.

Are there newer versions of those files?
Are you planning (or have you already) created a branch in
the SVN repository for later merging?
Any other thoughts what needs to be done or some kind of
"todo" list for the Win client?
What is your current status and interest in developing it
further?

One thing we have though about would be the possibility
to use put configuration data into the registry as an
alternative to the configuration text file.

Stefan


----- Original Message -----=20
From: "Nick Knight" <nick at omniis.com>
To: <boxbackup at fluffy.co.uk>
Sent: Wednesday, October 19, 2005 11:04 PM
Subject: RE: [unclassified] [Box Backup] Portability and public source
depot


> Hello Stephan,
>
> I would really be interested in your work on this...
>
> Regards
>
> Nick
>
> -----Original Message-----
> From: boxbackup-admin at fluffy.co.uk
[mailto:boxbackup-admin at fluffy.co.uk]
> On Behalf Of Stefan Norlin
> Sent: 13 October 2005 21:39
> To: boxbackup at fluffy.co.uk
> Subject: [unclassified] [Box Backup] Portability and public source
depot
>
> Hi,
>
> we have been using BoxBackup for a while. It works fine on Linux
> boxes.
>
> However, we would like to improve portability a bit. Both between
> different Linux boxes of different versions and to other OS:s as well.
> We are using AIX, FreeBSD, Linux, SCO OpenServer and Sun Solaris.
>
> There seems to be numerous changes (including Solaris port) since
> last release and I have seen discussions about a public depot for the
> source code and therefore it seems any effort put in should be done
> on as current code as possible.
>
> Any updates on the source code depot?
> Any comments regarding a portability effort?
>
> We are also using the Windows client by Nick Knight and are working
> on an improved installer to avoid having to edit config files by hand
> after installation.
>
> Regards,
> Stefan
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>
>
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>=20

_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Thu Oct 20 10:10:48 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Thu, 20 Oct 2005 10:10:48 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C573F@toutatis.omn11s.local>

Any wanting to offer help porting boxi would be great!! I did look at
this and it does use a portable windows toolkit wxWidgets.

-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
On Behalf Of Stefan Norlin
Sent: 19 October 2005 22:31
To: boxbackup at fluffy.co.uk
Subject: Re: [unclassified] [Box Backup] Portability and public source
depot

We are referring  to the command-line one. The Win port
of the "core" Box product.

I agree there is a need for a user interface in a longer perspective.
I have not looked at the boxi stuff yet, but that might be something
that is portable to Windows as well. It seems it runs under Cygwin
currently but claims to have the possibility of being cross platform.

As of now we are mainly interested in putting together a more
user-friendly installation with the possibility of entering config
parameters during the installation process. Then it would be
easy/easier to get it up and running on a Win box.

For restoring there are other alternatives for example via a simple
web-based UI or even a more manual approach.

>From our perspective:

Step 1, Being able to install the product easily and get files
backuped into the archive and having the possibility to restore
files even though it may be a bit tedious.

Step 2, Make the restore process more user-friendly as well.

Into which part would your potential contribution go?
The UI stuff?
If yes, maybe you could have a closer look at boxi and see what
it would take to get it up and running on a Windows box natively.

Stefan


----- Original Message -----=20
From: "Kai" <kai at kaos.gen.nz>
To: <boxbackup at fluffy.co.uk>
Sent: Wednesday, October 19, 2005 11:18 PM
Subject: RE: [unclassified] [Box Backup] Portability and public source
depot


> The major gripe I've had from people about the win client is lack of a

> user
> friendly GUI for config and restore.
>
> Which win client are you referring to here? The CMD line one or boxi?
>
> Just thinking if I might be able to contribute.
>
>> -----Original Message-----
>> From: boxbackup-admin at fluffy.co.uk
[mailto:boxbackup-admin at fluffy.co.uk]
>> On Behalf Of Stefan Norlin
>> Sent: Thursday, October 20, 2005 10:15 AM
>> To: boxbackup at fluffy.co.uk
>> Subject: Re: [unclassified] [Box Backup] Portability and public
source
>> depot
>>
>> Hi Nick,
>>
>> great. :)
>>
>> We are currently "idling" a bit waiting for all bits and pieces
>> to drop in to the repository and being merged until we put to
>> much effort into making larger changes.
>>
>> Regarding the Win client we have been using the source code
>> you made available some time ago in box0.09h.zip.
>>
>> Are there newer versions of those files?
>> Are you planning (or have you already) created a branch in
>> the SVN repository for later merging?
>> Any other thoughts what needs to be done or some kind of
>> "todo" list for the Win client?
>> What is your current status and interest in developing it
>> further?
>>
>> One thing we have though about would be the possibility
>> to use put configuration data into the registry as an
>> alternative to the configuration text file.
>>
>> Stefan
>>
>>
>> ----- Original Message -----
>> From: "Nick Knight" <nick at omniis.com>
>> To: <boxbackup at fluffy.co.uk>
>> Sent: Wednesday, October 19, 2005 11:04 PM
>> Subject: RE: [unclassified] [Box Backup] Portability and public
source
>> depot
>>
>>
>> > Hello Stephan,
>> >
>> > I would really be interested in your work on this...
>> >
>> > Regards
>> >
>> > Nick
>> >
>> > -----Original Message-----
>> > From: boxbackup-admin at fluffy.co.uk=20
>> > [mailto:boxbackup-admin at fluffy.co.uk]
>> > On Behalf Of Stefan Norlin
>> > Sent: 13 October 2005 21:39
>> > To: boxbackup at fluffy.co.uk
>> > Subject: [unclassified] [Box Backup] Portability and public source=20
>> > depot
>> >
>> > Hi,
>> >
>> > we have been using BoxBackup for a while. It works fine on Linux
>> > boxes.
>> >
>> > However, we would like to improve portability a bit. Both between
>> > different Linux boxes of different versions and to other OS:s as
well.
>> > We are using AIX, FreeBSD, Linux, SCO OpenServer and Sun Solaris.
>> >
>> > There seems to be numerous changes (including Solaris port) since
>> > last release and I have seen discussions about a public depot for
the
>> > source code and therefore it seems any effort put in should be done
>> > on as current code as possible.
>> >
>> > Any updates on the source code depot?
>> > Any comments regarding a portability effort?
>> >
>> > We are also using the Windows client by Nick Knight and are working
>> > on an improved installer to avoid having to edit config files by
hand
>> > after installation.
>> >
>> > Regards,
>> > Stefan
>> > _______________________________________________
>> > boxbackup mailing list
>> > boxbackup at fluffy.co.uk
>> > http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>> >
>> >
>> > _______________________________________________
>> > boxbackup mailing list
>> > boxbackup at fluffy.co.uk
>> > http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>> >
>>
>> _______________________________________________
>> boxbackup mailing list
>> boxbackup at fluffy.co.uk
>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>
>
> _______________________________________________
> boxbackup mailing list
> boxbackup at fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>=20

_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Thu Oct 20 13:04:50 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Thu, 20 Oct 2005 13:04:50 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <003a01c5d4f2$18c73610$0301050a@stenorhem>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local> <003a01c5d4f2$18c73610$0301050a@stenorhem>
Message-ID: <F9C95369-F7D7-4AA0-95ED-8FCD705C1CC1@fluffy.co.uk>

On 19 Oct 2005, at 22:14, Stefan Norlin wrote:

>
> We are currently "idling" a bit waiting for all bits and pieces
> to drop in to the repository and being merged until we put to
> much effort into making larger changes.

I think we need some SVN type advice from Martin now.

The win32 stuff has been made to a vaguely unknown version of Box  
Backup, probably 0.08 plus changes from 0.09. It's also likely to  
need a lot of tidying to make it fit well within the existing  
sources, not break anything, and be able to compile both UNIX and  
Win32 from the same tree.

What's the best way of approaching this problem?

Ben






From boxbackup at fluffy.co.uk  Sat Oct 22 21:54:02 2005
From: boxbackup at fluffy.co.uk (Chris Wilson)
Date: Sat, 22 Oct 2005 21:54:02 +0100 (BST)
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <004701c5d4f4$5b12e1c0$0301050a@stenorhem>
References: <E1ESLKr-0004to-00@grunt6.ihug.co.nz> <004701c5d4f4$5b12e1c0$0301050a@stenorhem>
Message-ID: <Pine.LNX.4.62.0510222134460.27878@top.qwarx.com>

Hi Stefan and all,

On Wed, 19 Oct 2005, Stefan Norlin wrote:

> We are referring  to the command-line one. The Win port
> of the "core" Box product.
>
> I agree there is a need for a user interface in a longer perspective.
> I have not looked at the boxi stuff yet, but that might be something
> that is portable to Windows as well. It seems it runs under Cygwin
> currently but claims to have the possibility of being cross platform.

Boxi was designed specifically to be cross-platform portable, and written 
using the wxWindows toolkit for that reason. I would be very interested 
and happy to help with the porting.

Since I don't use Windows and don't have any non-free compilers, it may 
not be easy for me to do all the work myself. Any contributions would be 
gratefully accepted :-) The source code is in Sourceforge CVS and anyone 
can download it and play with it. I'd be interested to know what breaks 
when compiling with MSVC or whatever compiler was used for the Box Backup 
win32 port.

The main thing that I know needs doing is to change the communication 
method used by Boxi on win32 from Unix sockets to TCP/IP ports, to match 
the native client. It should also be possible to compile for either 
version on Cygwin.

> As of now we are mainly interested in putting together a more
> user-friendly installation with the possibility of entering config
> parameters during the installation process. Then it would be
> easy/easier to get it up and running on a Win box.

I've been considering writing a web service with an HTML GUI that allows 
for easy registration and setup, but I haven't written any code yet. This 
would allow Boxi to generate new keys, upload them to the server, and get 
a signed cert automatically after the server admin has authorised it.

I think it's not easy to create keys and certificates on Win32 at the 
moment (OpenSSL is required?) and that should definitely be fixed. I think 
the code could be built into Boxi without too much trouble, but OpenSSL's 
APIs are complex and not well documented as far as I can see (if you know 
better then please point me to right part of TFM :-)

To make Boxi friendlier, it needs more information from Box Backup about 
backup progress and files which couldn't be backed up. I've already 
extended the command socket API but that needs to be merged into the newly 
open tree, and further work is necessary. It might be easier Boxi was 
itself a full-featured bbackupd, and didn't require a separate executable, 
but that would take quite a lot of work.

> If yes, maybe you could have a closer look at boxi and see what
> it would take to get it up and running on a Windows box natively.

By all means, please do, and let me know what I can do to help.

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |



From boxbackup at fluffy.co.uk  Sun Oct 23 23:52:17 2005
From: boxbackup at fluffy.co.uk (=?iso-8859-1?B?Sm/jbyBMde1z?=)
Date: Sun, 23 Oct 2005 23:52:17 +0100
Subject: [Box Backup] windows client
Message-ID: <000001c5d824$6dc8ddf0$9701000a@jjflm300>

Hello all,

I'm new to this forum. My name is joao luis, from Portugal.

I've made a test installation of Boxbackup for my company. The server is
running smoothly, the Linux client is running smoothly, but my Windows
clients don't. 
I've done the installation, the backup worked OK. But after the portable
has rebooted, the BoxBackup service doesn't start or when it start it
will die...
Where can I know what is causing this behaviour? The message box doesn't
help anything. It says that could be a windows problem, or driver
problem.

Thank's
joao




From boxbackup at fluffy.co.uk  Mon Oct 24 01:14:54 2005
From: boxbackup at fluffy.co.uk (Per Thomsen)
Date: Sun, 23 Oct 2005 17:14:54 -0700
Subject: [Box Backup] windows client
In-Reply-To: <000001c5d824$6dc8ddf0$9701000a@jjflm300>
References: <000001c5d824$6dc8ddf0$9701000a@jjflm300>
Message-ID: <435C277E.4060103@reedtz.com>

On 10/23/05 3:52 PM, Jo?o Lu?s wrote:
> Hello all,
>
> I'm new to this forum. My name is joao luis, from Portugal.
>
> I've made a test installation of Boxbackup for my company. The server is
> running smoothly, the Linux client is running smoothly, but my Windows
> clients don't. 
> I've done the installation, the backup worked OK. But after the portable
> has rebooted, the BoxBackup service doesn't start or when it start it
> will die...
> Where can I know what is causing this behaviour? The message box doesn't
> help anything. It says that could be a windows problem, or driver
> problem.
>   
I would start by looking in the event log on the Windows client: Control 
Panels -> Administrative tools -> Event Viewer

There should be some information there from the Windows client 
(bbackupd), giving you some clue as to what's going on. If you don't see 
anything that seems helpful, you might need to set the 'ExtendedLogging' 
parameter in the bbackupd.conf file to 'yes'. That will give you more 
data about the problem.

Hope this helps.

Thanks,
Per

-- 
Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119
V: 209 883 4102    |   pthomsen at reedtz.com  | C: 209 996 9561
GPG ID: 1209784F   |  Yahoo! Chat: pthomsen | AIM: pthomsen



From boxbackup at fluffy.co.uk  Mon Oct 24 06:20:17 2005
From: boxbackup at fluffy.co.uk (Mikael Syska)
Date: Mon, 24 Oct 2005 07:20:17 +0200
Subject: [Box Backup] windows client
In-Reply-To: <000001c5d824$6dc8ddf0$9701000a@jjflm300>
References: <000001c5d824$6dc8ddf0$9701000a@jjflm300>
Message-ID: <435C6F11.9070704@syska.dk>

Hey Joao,

Dont think there are much help to get, unless you provide additional 
information regarding the error?

Witch window client? winbox or boxi?

Can you start the windows client manualy?

What does it say if you start it from the command line?

mvh
Syska

Jo?o Lu?s wrote:

>Hello all,
>
>I'm new to this forum. My name is joao luis, from Portugal.
>
>I've made a test installation of Boxbackup for my company. The server is
>running smoothly, the Linux client is running smoothly, but my Windows
>clients don't. 
>I've done the installation, the backup worked OK. But after the portable
>has rebooted, the BoxBackup service doesn't start or when it start it
>will die...
>Where can I know what is causing this behaviour? The message box doesn't
>help anything. It says that could be a windows problem, or driver
>problem.
>
>Thank's
>joao
>
>
>_______________________________________________
>boxbackup mailing list
>boxbackup at fluffy.co.uk
>http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>  
>



From boxbackup at fluffy.co.uk  Mon Oct 24 10:03:50 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Mon, 24 Oct 2005 10:03:50 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57D1@toutatis.omn11s.local>

Hello all,

I agree, with everything said. If you have a windows box I will happily
donate a copy of Visual C++ .Net. If you want to commit to this then let
me know where to send a copy?

The windows version communicates over a named pipe - this I can help
with.

The web services would be great - can I also add something which screams
to the user to back up all of their keys!

More information over the command socket - I agree also I have a need to
monitor boxbackup and email is not a good thing for easily spotting
issues which require intervention.

Also Ben, can I have a login for the SVN?

Nick

-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
On Behalf Of Chris Wilson
Sent: 22 October 2005 21:54
To: boxbackup at fluffy.co.uk
Subject: Re: [unclassified] [Box Backup] Portability and public source
depot

Hi Stefan and all,

On Wed, 19 Oct 2005, Stefan Norlin wrote:

> We are referring  to the command-line one. The Win port
> of the "core" Box product.
>
> I agree there is a need for a user interface in a longer perspective.
> I have not looked at the boxi stuff yet, but that might be something
> that is portable to Windows as well. It seems it runs under Cygwin
> currently but claims to have the possibility of being cross platform.

Boxi was designed specifically to be cross-platform portable, and
written=20
using the wxWindows toolkit for that reason. I would be very interested=20
and happy to help with the porting.

Since I don't use Windows and don't have any non-free compilers, it may=20
not be easy for me to do all the work myself. Any contributions would be

gratefully accepted :-) The source code is in Sourceforge CVS and anyone

can download it and play with it. I'd be interested to know what breaks=20
when compiling with MSVC or whatever compiler was used for the Box
Backup=20
win32 port.

The main thing that I know needs doing is to change the communication=20
method used by Boxi on win32 from Unix sockets to TCP/IP ports, to match

the native client. It should also be possible to compile for either=20
version on Cygwin.

> As of now we are mainly interested in putting together a more
> user-friendly installation with the possibility of entering config
> parameters during the installation process. Then it would be
> easy/easier to get it up and running on a Win box.

I've been considering writing a web service with an HTML GUI that allows

for easy registration and setup, but I haven't written any code yet.
This=20
would allow Boxi to generate new keys, upload them to the server, and
get=20
a signed cert automatically after the server admin has authorised it.

I think it's not easy to create keys and certificates on Win32 at the=20
moment (OpenSSL is required?) and that should definitely be fixed. I
think=20
the code could be built into Boxi without too much trouble, but
OpenSSL's=20
APIs are complex and not well documented as far as I can see (if you
know=20
better then please point me to right part of TFM :-)

To make Boxi friendlier, it needs more information from Box Backup about

backup progress and files which couldn't be backed up. I've already=20
extended the command socket API but that needs to be merged into the
newly=20
open tree, and further work is necessary. It might be easier Boxi was=20
itself a full-featured bbackupd, and didn't require a separate
executable,=20
but that would take quite a lot of work.

> If yes, maybe you could have a closer look at boxi and see what
> it would take to get it up and running on a Windows box natively.

By all means, please do, and let me know what I can do to help.

Cheers, Chris.
--=20
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Mon Oct 24 11:04:32 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Mon, 24 Oct 2005 11:04:32 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <F9C95369-F7D7-4AA0-95ED-8FCD705C1CC1@fluffy.co.uk>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local>
 <003a01c5d4f2$18c73610$0301050a@stenorhem>
 <F9C95369-F7D7-4AA0-95ED-8FCD705C1CC1@fluffy.co.uk>
Message-ID: <1130148272.2735.10.camel@avenin.ebourne.me.uk>

On Thu, 2005-10-20 at 13:04 +0100, Ben Summers wrote:
> The win32 stuff has been made to a vaguely unknown version of Box  
> Backup, probably 0.08 plus changes from 0.09. It's also likely to  
> need a lot of tidying to make it fit well within the existing  
> sources, not break anything, and be able to compile both UNIX and  
> Win32 from the same tree.
> 
> What's the best way of approaching this problem?

It is perhaps a shame that you started the repository from 0.09, rather
than checking in older copies first. If 0.08 had been available I think
we could have branched from that, checked Nick's port in on top of it,
and then merged. I think any changes present in both copies would have
just been accepted.

However, I'm sure we can come up with something similar. I think the key
thing is that the win port must not be checked in on a branch from 0.09
or it will look like all the newer stuff has been deleted. Instead make
a new subdirectory in the repository, check in 0.08. Then check in
Nick's port on top of it. We should then be able to merge across from
there onto other branches or trunk.

Nick, if you've got the version of box you started working from, then
using that to seed the new directory instead of 0.08 would be even
better.

It's pretty easy to check a new tarball in on top of an old one - just
untar into the working copy, svn add new files, svn rm deleted files,
sanity check with svn st, then svn ci.

As to the tidying needed, we can work on that once it is in the
repository.

Any q's, just ask.

Cheers,

Martin.



From boxbackup at fluffy.co.uk  Mon Oct 24 11:11:38 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Mon, 24 Oct 2005 11:11:38 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <1130148272.2735.10.camel@avenin.ebourne.me.uk>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local> <003a01c5d4f2$18c73610$0301050a@stenorhem> <F9C95369-F7D7-4AA0-95ED-8FCD705C1CC1@fluffy.co.uk> <1130148272.2735.10.camel@avenin.ebourne.me.uk>
Message-ID: <8AE84341-5547-427D-914E-47587AFC3DBF@fluffy.co.uk>

On 24 Oct 2005, at 11:04, Martin Ebourne wrote:

> On Thu, 2005-10-20 at 13:04 +0100, Ben Summers wrote:
>
>> The win32 stuff has been made to a vaguely unknown version of Box
>> Backup, probably 0.08 plus changes from 0.09. It's also likely to
>> need a lot of tidying to make it fit well within the existing
>> sources, not break anything, and be able to compile both UNIX and
>> Win32 from the same tree.
>>
>> What's the best way of approaching this problem?
>>
>
> It is perhaps a shame that you started the repository from 0.09,  
> rather
> than checking in older copies first. If 0.08 had been available I  
> think
> we could have branched from that, checked Nick's port in on top of it,
> and then merged. I think any changes present in both copies would have
> just been accepted.
>
> However, I'm sure we can come up with something similar. I think  
> the key
> thing is that the win port must not be checked in on a branch from  
> 0.09
> or it will look like all the newer stuff has been deleted. Instead  
> make
> a new subdirectory in the repository, check in 0.08. Then check in
> Nick's port on top of it. We should then be able to merge across from
> there onto other branches or trunk.

This is complicated, as it needs to be a version which hasn't been  
prepared for release. Should I check in a version from my CVS to ben/ 
0_08 ?

Ben




From boxbackup at fluffy.co.uk  Mon Oct 24 11:15:51 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Mon, 24 Oct 2005 11:15:51 +0100
Subject: [Box Backup] FW: login
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57DF@toutatis.omn11s.local>

Question for the SVN experts out there.

I am putting in the windows port. As Ben said I need to put in the
original version that I worked on, then upload the differences.

I am unsure what box version I started working on - somewhere in 0.08
but I believe it may have had some of Bens patches in it.

What is going to be the best way to pull in this version (simplified
please I am not a svn expert!!!)

Thanks

Nick

-----Original Message-----
From: Ben Summers [mailto:ben at fluffy.co.uk]=20
Sent: 24 October 2005 10:58
To: Nick Knight
Subject: Re: login


On 24 Oct 2005, at 10:36, Nick Knight wrote:

> Thanks Ben,
>
> Not wishing to screw up you svn repository can I just run this pas =20
> you.
>
> I have a working copy of my boxbackup with the windows work in it. =20
> It is
> called boxworking. To upload I should change this to 'nick' then =20
> upload
> to your repository - which will create a nick folder?
>
> Is this correct?

I'm afraid that won't really do what we need.

You need to take the original files you started modifying, then do a =20
diff between them and your version with the -uw option. Then copy =20
trunk to nick/win32, check that out (NOT trunk), apply the diff, and =20
commit the modified files. Otherwise we lose all the lovely tracking =20
information.

I'm not an expert on this, so if you're not sure, ask on the list. =20
Martin appears to know all about this stuff.

Thanks,

Ben









From boxbackup at fluffy.co.uk  Mon Oct 24 11:22:20 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Mon, 24 Oct 2005 11:22:20 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <8AE84341-5547-427D-914E-47587AFC3DBF@fluffy.co.uk>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local>
 <003a01c5d4f2$18c73610$0301050a@stenorhem>
 <F9C95369-F7D7-4AA0-95ED-8FCD705C1CC1@fluffy.co.uk>
 <1130148272.2735.10.camel@avenin.ebourne.me.uk>
 <8AE84341-5547-427D-914E-47587AFC3DBF@fluffy.co.uk>
Message-ID: <1130149340.2735.15.camel@avenin.ebourne.me.uk>

On Mon, 2005-10-24 at 11:11 +0100, Ben Summers wrote:
> This is complicated, as it needs to be a version which hasn't been  
> prepared for release. Should I check in a version from my CVS to ben/ 
> 0_08 ?

Yes, that should work.

You had box in CVS? Is there any reason you didn't just run cvs2svn to
convert the whole thing?

Cheers,

Martin.



From boxbackup at fluffy.co.uk  Mon Oct 24 11:26:17 2005
From: boxbackup at fluffy.co.uk (dave bamford)
Date: Mon, 24 Oct 2005 11:26:17 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <1130148272.2735.10.camel@avenin.ebourne.me.uk>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local>	 <003a01c5d4f2$18c73610$0301050a@stenorhem>	 <F9C95369-F7D7-4AA0-95ED-8FCD705C1CC1@fluffy.co.uk> <1130148272.2735.10.camel@avenin.ebourne.me.uk>
Message-ID: <435CB6C9.5020805@logical-progress.com>

Martin Ebourne wrote:

>On Thu, 2005-10-20 at 13:04 +0100, Ben Summers wrote:
>  
>
>>The win32 stuff has been made to a vaguely unknown version of Box  
>>Backup, probably 0.08 plus changes from 0.09. It's also likely to  
>>need a lot of tidying to make it fit well within the existing  
>>sources, not break anything, and be able to compile both UNIX and  
>>Win32 from the same tree.
>>
>>What's the best way of approaching this problem?
>>    
>>
>
>It is perhaps a shame that you started the repository from 0.09, rather
>than checking in older copies first. If 0.08 had been available I think
>we could have branched from that, checked Nick's port in on top of it,
>and then merged. I think any changes present in both copies would have
>just been accepted.
>
>However, I'm sure we can come up with something similar. I think the key
>thing is that the win port must not be checked in on a branch from 0.09
>or it will look like all the newer stuff has been deleted. Instead make
>a new subdirectory in the repository, check in 0.08. Then check in
>Nick's port on top of it. We should then be able to merge across from
>there onto other branches or trunk.
>
>Nick, if you've got the version of box you started working from, then
>using that to seed the new directory instead of 0.08 would be even
>better.
>
>It's pretty easy to check a new tarball in on top of an old one - just
>untar into the working copy, svn add new files, svn rm deleted files,
>sanity check with svn st, then svn ci.
>
>As to the tidying needed, we can work on that once it is in the
>repository.
>
>Any q's, just ask.
>
>Cheers,
>
>Martin.
>  
>
Hi
I have just compiled an OS2 port and would like to get this incorporated.
I used the existing win32 port as a starting point and defined an OS2
variable. As OS2 is more unix like than win there were less changes
needed, the only bugbear was vfork, which was skipped by the win32
port too. the only others that had to be added were poll and syslog.

I am currently in the process of testing, all modules compiled, server
and client.

I can easily go back to a clean tarball and do the mods on this, my main
problems were with the configure program, I had to frig it a bit and edit
the makefiles slightly. Autoconfigure would be good.

Dave Bamford.


From boxbackup at fluffy.co.uk  Mon Oct 24 11:25:43 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Mon, 24 Oct 2005 11:25:43 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <1130149340.2735.15.camel@avenin.ebourne.me.uk>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local> <003a01c5d4f2$18c73610$0301050a@stenorhem> <F9C95369-F7D7-4AA0-95ED-8FCD705C1CC1@fluffy.co.uk> <1130148272.2735.10.camel@avenin.ebourne.me.uk> <8AE84341-5547-427D-914E-47587AFC3DBF@fluffy.co.uk> <1130149340.2735.15.camel@avenin.ebourne.me.uk>
Message-ID: <1CC09B2F-D213-440D-B697-AC223BDD40B3@fluffy.co.uk>

On 24 Oct 2005, at 11:22, Martin Ebourne wrote:

> On Mon, 2005-10-24 at 11:11 +0100, Ben Summers wrote:
>
>> This is complicated, as it needs to be a version which hasn't been
>> prepared for release. Should I check in a version from my CVS to ben/
>> 0_08 ?
>>
>
> Yes, that should work.
>
> You had box in CVS? Is there any reason you didn't just run cvs2svn to
> convert the whole thing?

The backup element is part of a bigger project, so there was quite a  
bit of extra code in there I didn't feel like releasing.

Also, I'm lazy.

Ben






From boxbackup at fluffy.co.uk  Mon Oct 24 11:28:13 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Mon, 24 Oct 2005 11:28:13 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <435CB6C9.5020805@logical-progress.com>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local>	 <003a01c5d4f2$18c73610$0301050a@stenorhem>	 <F9C95369-F7D7-4AA0-95ED-8FCD705C1CC1@fluffy.co.uk> <1130148272.2735.10.camel@avenin.ebourne.me.uk> <435CB6C9.5020805@logical-progress.com>
Message-ID: <6F6FDEA8-F146-4424-AF5F-ADD7FC37EEE3@fluffy.co.uk>

On 24 Oct 2005, at 11:26, dave bamford wrote:

> Hi
> I have just compiled an OS2 port and would like to get this  
> incorporated.
> I used the existing win32 port as a starting point and defined an OS2
> variable. As OS2 is more unix like than win there were less changes
> needed, the only bugbear was vfork, which was skipped by the win32
> port too. the only others that had to be added were poll and syslog.
>
> I am currently in the process of testing, all modules compiled, server
> and client.
>
> I can easily go back to a clean tarball and do the mods on this, my  
> main
> problems were with the configure program, I had to frig it a bit  
> and edit
> the makefiles slightly. Autoconfigure would be good.

It might be best to wait until the autoconf version is merged in, and  
then import the necessary patches after that?

Once we've got Nick's stuff in, I will take a good look at all the  
changes and propose a plan for merging them all.

Ben






From boxbackup at fluffy.co.uk  Mon Oct 24 11:29:33 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Mon, 24 Oct 2005 11:29:33 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <435CB6C9.5020805@logical-progress.com>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5739@toutatis.omn11s.local>
 <003a01c5d4f2$18c73610$0301050a@stenorhem>
 <F9C95369-F7D7-4AA0-95ED-8FCD705C1CC1@fluffy.co.uk>
 <1130148272.2735.10.camel@avenin.ebourne.me.uk>
 <435CB6C9.5020805@logical-progress.com>
Message-ID: <1130149774.2735.17.camel@avenin.ebourne.me.uk>

On Mon, 2005-10-24 at 11:26 +0100, dave bamford wrote:
> I can easily go back to a clean tarball and do the mods on this, my main
> problems were with the configure program, I had to frig it a bit and edit
> the makefiles slightly. Autoconfigure would be good.

In which case, it might be best to wait until everything in the
repository is merged. There's an autoconf port in there already. Then
hopefully you'll have very few changes to redo.

Cheers,

Martin.



From boxbackup at fluffy.co.uk  Mon Oct 24 12:44:26 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Mon, 24 Oct 2005 12:44:26 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57E9@toutatis.omn11s.local>

Ok I think I have it now

Untar a version of 0.08 in a directory called nick
Check it in
Untar my port over the top then update svn

I have been working on the files with no header (copyright stuff) in
them - is this the correct version to merge in?

-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
On Behalf Of Martin Ebourne
Sent: 24 October 2005 11:05
To: boxbackup at fluffy.co.uk
Subject: Re: [unclassified] [Box Backup] Portability and public source
depot

On Thu, 2005-10-20 at 13:04 +0100, Ben Summers wrote:
> The win32 stuff has been made to a vaguely unknown version of Box =20
> Backup, probably 0.08 plus changes from 0.09. It's also likely to =20
> need a lot of tidying to make it fit well within the existing =20
> sources, not break anything, and be able to compile both UNIX and =20
> Win32 from the same tree.
>=20
> What's the best way of approaching this problem?

It is perhaps a shame that you started the repository from 0.09, rather
than checking in older copies first. If 0.08 had been available I think
we could have branched from that, checked Nick's port in on top of it,
and then merged. I think any changes present in both copies would have
just been accepted.

However, I'm sure we can come up with something similar. I think the key
thing is that the win port must not be checked in on a branch from 0.09
or it will look like all the newer stuff has been deleted. Instead make
a new subdirectory in the repository, check in 0.08. Then check in
Nick's port on top of it. We should then be able to merge across from
there onto other branches or trunk.

Nick, if you've got the version of box you started working from, then
using that to seed the new directory instead of 0.08 would be even
better.

It's pretty easy to check a new tarball in on top of an old one - just
untar into the working copy, svn add new files, svn rm deleted files,
sanity check with svn st, then svn ci.

As to the tidying needed, we can work on that once it is in the
repository.

Any q's, just ask.

Cheers,

Martin.

_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Mon Oct 24 12:49:36 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Mon, 24 Oct 2005 12:49:36 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57E9@toutatis.omn11s.local>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57E9@toutatis.omn11s.local>
Message-ID: <1130154577.2735.21.camel@avenin.ebourne.me.uk>

On Mon, 2005-10-24 at 12:44 +0100, Nick Knight wrote:
> Ok I think I have it now
> 
> Untar a version of 0.08 in a directory called nick
> Check it in

I think Ben is doing that himself (unless you have the exact version
before you started changing, which would be better).

Otherwise once Ben is done you should be able to just:
svn mkdir nick
svn cp ben/0_08 nick/win

Then:

> Untar my port over the top then update svn
> 
> I have been working on the files with no header (copyright stuff) in
> them - is this the correct version to merge in?

Yep.

Cheers,

Martin.



From boxbackup at fluffy.co.uk  Mon Oct 24 13:23:05 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Mon, 24 Oct 2005 13:23:05 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57ED@toutatis.omn11s.local>

Ok - I will wait for Ben to do his bit...

Do I have to then check out the 0.08 or is there an easier way with svn?

-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
On Behalf Of Martin Ebourne
Sent: 24 October 2005 12:50
To: boxbackup at fluffy.co.uk
Subject: RE: [unclassified] [Box Backup] Portability and public source
depot

On Mon, 2005-10-24 at 12:44 +0100, Nick Knight wrote:
> Ok I think I have it now
>=20
> Untar a version of 0.08 in a directory called nick
> Check it in

I think Ben is doing that himself (unless you have the exact version
before you started changing, which would be better).

Otherwise once Ben is done you should be able to just:
svn mkdir nick
svn cp ben/0_08 nick/win

Then:

> Untar my port over the top then update svn
>=20
> I have been working on the files with no header (copyright stuff) in
> them - is this the correct version to merge in?

Yep.

Cheers,

Martin.

_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Mon Oct 24 13:29:48 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Mon, 24 Oct 2005 13:29:48 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57ED@toutatis.omn11s.local>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57ED@toutatis.omn11s.local>
Message-ID: <1130156988.2735.24.camel@avenin.ebourne.me.uk>

On Mon, 2005-10-24 at 13:23 +0100, Nick Knight wrote:
> Ok - I will wait for Ben to do his bit...
> 
> Do I have to then check out the 0.08 or is there an easier way with svn?

Just check out the whole thing for now.

svn co http://bbdev.fluffy.co.uk/svn/box/

Cheers,

Martin.



From boxbackup at fluffy.co.uk  Mon Oct 24 13:42:53 2005
From: boxbackup at fluffy.co.uk (=?iso-8859-1?B?Sm/jbyBMde1z?=)
Date: Mon, 24 Oct 2005 13:42:53 +0100
Subject: [Box Backup] FW: windows client
Message-ID: <002b01c5d898$746ee360$6439a8c0@jjflm300>

Now when I try to reinstall the SW, when I'm try to register the service
I receive this message:
C:\Program Files\Box Backup>bbackupd -i
No random device -- additional seeding of random number generator not
performed.

What can I do? It has worked before...

This is an Armada m300, with Win2k.

Thanks,
-----Original Message-----
From: Jo=E3o Lu=EDs [mailto:jjflluis at zmail.pt]=20
Sent: domingo, 23 de Outubro de 2005 23:52
To: 'boxbackup at fluffy.co.uk'
Subject: windows client

Hello all,

I'm new to this forum. My name is joao luis, from Portugal.

I've made a test installation of Boxbackup for my company. The server is
running smoothly, the Linux client is running smoothly, but my Windows
clients don't.=20
I've done the installation, the backup worked OK. But after the portable
has rebooted, the BoxBackup service doesn't start or when it start it
will die...
Where can I know what is causing this behaviour? The message box doesn't
help anything. It says that could be a windows problem, or driver
problem.

Thank's
joao




From boxbackup at fluffy.co.uk  Mon Oct 24 13:59:19 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Mon, 24 Oct 2005 13:59:19 +0100
Subject: [unclassified] [Box Backup] Portability and public source depot
In-Reply-To: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57ED@toutatis.omn11s.local>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57ED@toutatis.omn11s.local>
Message-ID: <B615D901-D183-44DD-920B-AED7244FA43B@fluffy.co.uk>

On 24 Oct 2005, at 13:23, Nick Knight wrote:

> Ok - I will wait for Ben to do his bit...

http://bbdev.fluffy.co.uk/svn/box/ben/box0_08/

There you go!

Ben




From boxbackup at fluffy.co.uk  Mon Oct 24 14:00:36 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Mon, 24 Oct 2005 14:00:36 +0100
Subject: [Box Backup] FW: windows client
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C57F8@toutatis.omn11s.local>

That's perfectly normal message you will always get that, are there any =
more meesages?

-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] =
On Behalf Of Jo=E3o Lu=EDs
Sent: 24 October 2005 13:43
To: boxbackup at fluffy.co.uk
Subject: [Box Backup] FW: windows client

Now when I try to reinstall the SW, when I'm try to register the service
I receive this message:
C:\Program Files\Box Backup>bbackupd -i
No random device -- additional seeding of random number generator not
performed.

What can I do? It has worked before...

This is an Armada m300, with Win2k.

Thanks,
-----Original Message-----
From: Jo=E3o Lu=EDs [mailto:jjflluis at zmail.pt]=20
Sent: domingo, 23 de Outubro de 2005 23:52
To: 'boxbackup at fluffy.co.uk'
Subject: windows client

Hello all,

I'm new to this forum. My name is joao luis, from Portugal.

I've made a test installation of Boxbackup for my company. The server is
running smoothly, the Linux client is running smoothly, but my Windows
clients don't.=20
I've done the installation, the backup worked OK. But after the portable
has rebooted, the BoxBackup service doesn't start or when it start it
will die...
Where can I know what is causing this behaviour? The message box doesn't
help anything. It says that could be a windows problem, or driver
problem.

Thank's
joao


_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Mon Oct 24 21:19:27 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Mon, 24 Oct 2005 21:19:27 +0100
Subject: [Box Backup] Win32
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5826@toutatis.omn11s.local>

I think - is in svn now. I haven't tested a check out or build though!!!

Regards

Nick



From boxbackup at fluffy.co.uk  Mon Oct 24 23:19:25 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Mon, 24 Oct 2005 23:19:25 +0100
Subject: [Box Backup] Win32
In-Reply-To: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5826@toutatis.omn11s.local>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5826@toutatis.omn11s.local>
Message-ID: <1130192365.2735.37.camel@avenin.ebourne.me.uk>

On Mon, 2005-10-24 at 21:19 +0100, Nick Knight wrote:
> I think - is in svn now. I haven't tested a check out or build though!!!

Well it certainly seems to be in there. Including the whole of boost!

Am I right in thinking you only use boost to provide the regex library,
as a substitute for unix regex?

Maybe you've already discussed this with Ben, but I feel that including
the whole of boost inside box is not the right thing to be doing here.
It's too large a dependency to be incorporated and it's got a very
stable interface too, so there's not really any need.

Really it ought to be an external requirement, and then only on
platforms that need it.

Not that I'm arguing against the use of boost, it's a good library and I
encourage people to use it. Just don't think we should be incorporating
it in the sources.

Cheers,

Martin.



From boxbackup at fluffy.co.uk  Tue Oct 25 00:37:28 2005
From: boxbackup at fluffy.co.uk (Martin Ebourne)
Date: Tue, 25 Oct 2005 00:37:28 +0100
Subject: [Box Backup] Win32
In-Reply-To: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5826@toutatis.omn11s.local>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5826@toutatis.omn11s.local>
Message-ID: <1130197048.2735.55.camel@avenin.ebourne.me.uk>

On Mon, 2005-10-24 at 21:19 +0100, Nick Knight wrote:
> I think - is in svn now. I haven't tested a check out or build though!!!

Well the plan seems to have worked anyhow.

I've made a copy of your stuff (sans boost) in martin/test so I could
try things out on it. Firstly I merged it onto trunk (in my working copy
only!) to be up to date with box 0.09. This generated a whole bunch of
conflicts. On investigation it was the bad old line feed issue causing
whole file conflicts.

[ ASIDE: At some point we should set the svn:eol-style property on all
files. This should then prevent the linefeeds from being a problem by
making subversion do the conversion as appropriate. See
http://svnbook.red-bean.com/en/1.1/ch07s02.html for more info. Probably
after it's all merged into trunk would be a good time. ]

For now I've dos2unixed all apart from the windows files in martin/test.
After that, the merge was fine. There were 3 conflicts, all of which
were Nick removing BOX PRIVATE lines so those are easy to solve.

The results look sane, though I've not attempted to compile them.

I then went on to merge all the other branches (except autoconf) in my
working copy. On average I got one conflict from each, almost all minor.

Then finally I merged autoconf, which amazingly only got 4 files
conflicted, again nothing too drastic to sort out. However, this isn't
the whole story since there'll need to be some work done on the windows
changes to make sure they're fully autoconfed too.

Note that I'm not proposing we go ahead and merge right now - obviously
there's cleanup needed in some cases, and code review in all.

Cheers,

Martin.



From boxbackup at fluffy.co.uk  Tue Oct 25 10:49:10 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Tue, 25 Oct 2005 10:49:10 +0100
Subject: [Box Backup] Win32
In-Reply-To: <1130192365.2735.37.camel@avenin.ebourne.me.uk>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5826@toutatis.omn11s.local> <1130192365.2735.37.camel@avenin.ebourne.me.uk>
Message-ID: <404CFFFE-8219-49E3-ABBD-71AF9FF4B6EC@fluffy.co.uk>

On 24 Oct 2005, at 23:19, Martin Ebourne wrote:

> On Mon, 2005-10-24 at 21:19 +0100, Nick Knight wrote:
>
>> I think - is in svn now. I haven't tested a check out or build  
>> though!!!
>>
>
> Well it certainly seems to be in there. Including the whole of boost!
>
> Am I right in thinking you only use boost to provide the regex  
> library,
> as a substitute for unix regex?
>
> Maybe you've already discussed this with Ben, but I feel that  
> including
> the whole of boost inside box is not the right thing to be doing here.
> It's too large a dependency to be incorporated and it's got a very
> stable interface too, so there's not really any need.

I think it's too large as well. It would be much nicer to make it  
optional, and perhaps use something like pcre which is small(ish) and  
readily available as a pre-build dll. Perhaps even going as far as  
dynamically loading the pcre library if it's available, and disabling  
this functionality if it's not.

In the meantime, can we remove boost? regexes aren't that important  
really, at least for the next stage of getting the port integrated  
into the tree.

Ben






From boxbackup at fluffy.co.uk  Tue Oct 25 11:00:49 2005
From: boxbackup at fluffy.co.uk (Stefan Norlin)
Date: Tue, 25 Oct 2005 12:00:49 +0200
Subject: [Box Backup] Win32
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5826@toutatis.omn11s.local> <1130192365.2735.37.camel@avenin.ebourne.me.uk> <404CFFFE-8219-49E3-ABBD-71AF9FF4B6EC@fluffy.co.uk>
Message-ID: <017601c5d94a$fa1d2af0$1601060a@cs>

> I think it's too large as well. It would be much nicer to make it 
> optional, and perhaps use something like pcre which is small(ish) and 
> readily available as a pre-build dll. Perhaps even going as far as 
> dynamically loading the pcre library if it's available, and disabling 
> this functionality if it's not.

I tried to compile Boxi in Windows. One of the relatively few problems
I came across was it's requirement of a regex package (which can be
commented out easily though).

Since Box and Boxi both have external dependencies it would be nice
if these could be "harmonized" so that one well defined set of external
libraries (and include files) would satisfy all dependencies in both 
products.

When compiling Win port of Box what took most of the time was to
get all dependencies in correct places. As Martin mentions the interfaces
are quite stable in all of these external products.

Stefan



From boxbackup at fluffy.co.uk  Tue Oct 25 21:28:30 2005
From: boxbackup at fluffy.co.uk (Chris Wilson)
Date: Tue, 25 Oct 2005 21:28:30 +0100 (BST)
Subject: [Box Backup] Win32
In-Reply-To: <017601c5d94a$fa1d2af0$1601060a@cs>
References: <A1501BC8C03ACC44B4C56ADC68B1C7F93C5826@toutatis.omn11s.local>
 <1130192365.2735.37.camel@avenin.ebourne.me.uk> <404CFFFE-8219-49E3-ABBD-71AF9FF4B6EC@fluffy.co.uk>
 <017601c5d94a$fa1d2af0$1601060a@cs>
Message-ID: <Pine.LNX.4.62.0510252125340.32101@top.qwarx.com>

Hi Stefan,

On Tue, 25 Oct 2005, Stefan Norlin wrote:

> I tried to compile Boxi in Windows. One of the relatively few problems
> I came across was it's requirement of a regex package (which can be
> commented out easily though).
>
> Since Box and Boxi both have external dependencies it would be nice
> if these could be "harmonized" so that one well defined set of external
> libraries (and include files) would satisfy all dependencies in both 
> products.

Please could you give more details about which regexp library Boxi depends 
on that Box doesn't? Maybe I'm blind at the moment, but I can't find it.

In theory, I think Box and Boxi (at least the latest Boxi from CVS) use 
the same regexp library. In any case, you must be able to build Box under 
cygwin (with all its dependencies) to build Boxi.

What did you comment out to make it work for you?

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |



From boxbackup at fluffy.co.uk  Wed Oct 26 09:10:55 2005
From: boxbackup at fluffy.co.uk (Nick Knight)
Date: Wed, 26 Oct 2005 09:10:55 +0100
Subject: [Box Backup] Win32
Message-ID: <A1501BC8C03ACC44B4C56ADC68B1C7F93C584D@toutatis.omn11s.local>

Happy to take the guidance on boost - I left it in because of another
opensource project I have written and the common request (when I left
out boost) was can you please add it.

The main downside is the size of boost, another option to the ones
discussed is to strip out only the regex files (which are quite small)
or someone point me to the other regex library....

-----Original Message-----
From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk]
On Behalf Of Martin Ebourne
Sent: 24 October 2005 23:19
To: boxbackup at fluffy.co.uk
Subject: Re: [Box Backup] Win32

On Mon, 2005-10-24 at 21:19 +0100, Nick Knight wrote:
> I think - is in svn now. I haven't tested a check out or build
though!!!

Well it certainly seems to be in there. Including the whole of boost!

Am I right in thinking you only use boost to provide the regex library,
as a substitute for unix regex?

Maybe you've already discussed this with Ben, but I feel that including
the whole of boost inside box is not the right thing to be doing here.
It's too large a dependency to be incorporated and it's got a very
stable interface too, so there's not really any need.

Really it ought to be an external requirement, and then only on
platforms that need it.

Not that I'm arguing against the use of boost, it's a good library and I
encourage people to use it. Just don't think we should be incorporating
it in the sources.

Cheers,

Martin.

_______________________________________________
boxbackup mailing list
boxbackup at fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup




From boxbackup at fluffy.co.uk  Mon Oct 31 06:26:43 2005
From: boxbackup at fluffy.co.uk (Scott McNee)
Date: Mon, 31 Oct 2005 16:26:43 +1000
Subject: [Box Backup] Running daemons in foreground
Message-ID: <000601c5dde4$131a2650$be01a8c0@SCOTTLAPTOP>

Is it possible to run the daemon's in the foreground ?
Ie. Bbackupd and bbstored

I am investigating the use of daemontools as a method to ensure that the
process is running. They suggest that all process should be run in the
foreground enabling tighter control by daemontools utils.

Any help would be appreciated.

Thank you
Scott




From boxbackup at fluffy.co.uk  Mon Oct 31 07:57:11 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Mon, 31 Oct 2005 07:57:11 +0000
Subject: [Box Backup] Running daemons in foreground
In-Reply-To: <000601c5dde4$131a2650$be01a8c0@SCOTTLAPTOP>
References: <000601c5dde4$131a2650$be01a8c0@SCOTTLAPTOP>
Message-ID: <FA571250-8ED6-4616-8167-724D0108072B@fluffy.co.uk>

On 31 Oct 2005, at 06:26, Scott McNee wrote:

>
> Is it possible to run the daemon's in the foreground ?
> Ie. Bbackupd and bbstored
>
> I am investigating the use of daemontools as a method to ensure  
> that the
> process is running. They suggest that all process should be run in the
> foreground enabling tighter control by daemontools utils.
>
> Any help would be appreciated.

There's an undocumented option (for all daemons)

     bbackupd /path/to/bbackupd.conf SINGLEPROCESS

which may do what you want.

Ben




From boxbackup at fluffy.co.uk  Mon Oct 31 16:45:22 2005
From: boxbackup at fluffy.co.uk (boxbackup at fluffy.co.uk)
Date: Mon, 31 Oct 2005 10:45:22 -0600
Subject: [Box Backup] failed tests from "make test" in obsd 3.8-current
Message-ID: <8c6959fa.53f4d953.8203000@m4500-00.uchicago.edu>

-------ddf93f2a4541ede035ce6ca3ec9f95ce
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

heya,

i'm compiling boxbackup-0.09 and i have no problems
configuring and making, but when i run the "make test" i
notice that it fails a number of these tests. i'm running
openbsd 3.8-current on a machine that will soon run
3.8-release and has a hardware RAID 1 array (2x200GB). here is
the output of the failed tests:

common: PASSED
crypto: PASSED
compress: PASSED
basicserver: PASSED
raidfile: PASSED
backupstore: FAILED: 2 tests failed
backupstorefix: FAILED: 2 tests failed
backupstorepatch: FAILED: 2 tests failed
backupdiff: PASSED
bbackupd: FAILED: 2 tests failed

i've attached the full output of the "make test", in case that
holds additional useful information. i can send along a dmesg
if that would help.

regards,
jake

-------ddf93f2a4541ede035ce6ca3ec9f95ce
Content-Type: application/octet-stream;
	name="make.test.out"
Content-Disposition: inline;
	filename="make.test.out"
Content-Transfer-Encoding: base64

Li9ydW50ZXN0LnBsIEFMTCByZWxlYXNlCihjZCAuLi8uLi9saWIvY29tbW9uOyBtYWtlIC1E
IFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL2NvbW1vbi5h
JyBpcyB1cCB0byBkYXRlLgpgLi4vLi4vcmVsZWFzZS90ZXN0L2NvbW1vbi90ZXN0JyBpcyB1
cCB0byBkYXRlLgpURVNUOiB0ZXN0L2NvbW1vbgpSZW1vdmluZyBvbGQgdGVzdCBmaWxlcy4u
LgpDb3B5aW5nIG5ldyB0ZXN0IGZpbGVzLi4uClJ1bm5pbmcgdGVzdCBjb21tb24gaW4gcmVs
ZWFzZSBtb2RlLi4uCih0ZXN0ZmlsZXMvY29uZmlnMi50eHQpIEVycm9yIG1zZyBpczoKLS0t
LS0tCjxyb290Pi5UT1BsZXZlbCAoa2V5KSBpcyBtaXNzaW5nLgotLS0tLS0KKHRlc3RmaWxl
cy9jb25maWczLnR4dCkgRXJyb3IgbXNnIGlzOgotLS0tLS0KVW5leHBlY3RlZCBzdGFydCBi
bG9jayBpbiB0ZXN0MQotLS0tLS0KKHRlc3RmaWxlcy9jb25maWc0LnR4dCkgRXJyb3IgbXNn
IGlzOgotLS0tLS0KUm9vdCBsZXZlbCBoYXMgY2xvc2UgYmxvY2sgLS0gZm9yZ2V0IHRvIHRl
cm1pbmF0ZSBzdWJibG9jaz8KLS0tLS0tCih0ZXN0ZmlsZXMvY29uZmlnNS50eHQpIEVycm9y
IG1zZyBpczoKLS0tLS0tCkJsb2NrIHN1YmNvbmZpZzIgd2Fzbid0IHN0YXJ0ZWQgY29ycmVj
dGx5IChubyAneycgb24gbGluZSBvZiBpdCdzIG93bikKUm9vdCBsZXZlbCBoYXMgY2xvc2Ug
YmxvY2sgLS0gZm9yZ2V0IHRvIHRlcm1pbmF0ZSBzdWJibG9jaz8KLS0tLS0tCih0ZXN0Zmls
ZXMvY29uZmlnNi50eHQpIEVycm9yIG1zZyBpczoKLS0tLS0tCnRlc3QxLnN1YmNvbmZpZzIu
YmluZyAoa2V5KSBtdWx0aSB2YWx1ZSBub3QgYWxsb3dlZCAoZHVwbGljYXRlZCBrZXk/KS4K
LS0tLS0tCih0ZXN0ZmlsZXMvY29uZmlnNy50eHQpIEVycm9yIG1zZyBpczoKLS0tLS0tCklu
dmFsaWQga2V5IGluIGJsb2NrIHN1YmNvbmZpZzMKLS0tLS0tCih0ZXN0ZmlsZXMvY29uZmln
OC50eHQpIEVycm9yIG1zZyBpczoKLS0tLS0tCkZpbGUgZW5kZWQgd2l0aG91dCB0ZXJtaW5h
dGluZyBhbGwgc3ViYmxvY2tzCi0tLS0tLQoodGVzdGZpbGVzL2NvbmZpZzkudHh0KSBFcnJv
ciBtc2cgaXM6Ci0tLS0tLQp0ZXN0MS5zdWJjb25maWczLmNhcnJvdHMgKGtleSkgaXMgbm90
IGEgdmFsaWQgaW50ZWdlci4KLS0tLS0tCih0ZXN0ZmlsZXMvY29uZmlnOWIudHh0KSBFcnJv
ciBtc2cgaXM6Ci0tLS0tLQp0ZXN0MS5zdWJjb25maWcyLmNhcnJvdHMgKGtleSkgaXMgbm90
IGEgdmFsaWQgaW50ZWdlci4KLS0tLS0tCih0ZXN0ZmlsZXMvY29uZmlnOWMudHh0KSBFcnJv
ciBtc2cgaXM6Ci0tLS0tLQp0ZXN0MS5zdWJjb25maWcyLmNhcnJvdHMgKGtleSkgaXMgbm90
IGEgdmFsaWQgaW50ZWdlci4KLS0tLS0tCih0ZXN0ZmlsZXMvY29uZmlnOWQudHh0KSBFcnJv
ciBtc2cgaXM6Ci0tLS0tLQp0ZXN0MS5zdWJjb25maWczLmNhcnJvdHMgKGtleSkgaXMgbm90
IGEgdmFsaWQgaW50ZWdlci4KLS0tLS0tCih0ZXN0ZmlsZXMvY29uZmlnMTAudHh0KSBFcnJv
ciBtc2cgaXM6Ci0tLS0tLQp0ZXN0MS5zdWJjb25maWcuY2Fycm90cyAoa2V5KSBpcyBtaXNz
aW5nLgotLS0tLS0KKHRlc3RmaWxlcy9jb25maWcxMS50eHQpIEVycm9yIG1zZyBpczoKLS0t
LS0tCnRlc3QxLnN1YmNvbmZpZzMuTk9URVhQRUNURUQgKGtleSkgaXMgbm90IGEga25vd24g
a2V5LiBDaGVjayBzcGVsbGluZyBhbmQgcGxhY2VtZW50LgotLS0tLS0KKHRlc3RmaWxlcy9j
b25maWcxMi50eHQpIEVycm9yIG1zZyBpczoKLS0tLS0tCjxyb290Pi50ZXN0MS5vdGhlcnRo
aW5nIChibG9jaykgaXMgbWlzc2luZy4KLS0tLS0tCih0ZXN0ZmlsZXMvY29uZmlnMTMudHh0
KSBFcnJvciBtc2cgaXM6Ci0tLS0tLQo8cm9vdD4udGVzdDEuKiAoYmxvY2spIGlzIG1pc3Np
bmcgKGEgYmxvY2sgbXVzdCBiZSBwcmVzZW50KS4KPHJvb3Q+LnRlc3QxLm90aGVydGhpbmcg
KGJsb2NrKSBpcyBtaXNzaW5nLgotLS0tLS0KKHRlc3RmaWxlcy9jb25maWcxNi50eHQpIEVy
cm9yIG1zZyBpczoKLS0tLS0tCjxyb290Pi5Cb29sVHJ1ZTEgKGtleSkgaXMgbm90IGEgdmFs
aWQgYm9vbGVhbiB2YWx1ZS4KLS0tLS0tClBBU1NFRAooY2QgLi4vLi4vbGliL2NvbW1vbjsg
bWFrZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvbGliL2NvbW1vbi9j
b21tb24uYScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9jcnlwdG87IG1ha2UgLUQg
UkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9jcnlwdG8vY3J5cHRvLmEn
IGlzIHVwIHRvIGRhdGUuCmAuLi8uLi9yZWxlYXNlL3Rlc3QvY3J5cHRvL3Rlc3QnIGlzIHVw
IHRvIGRhdGUuClRFU1Q6IHRlc3QvY3J5cHRvClJ1bm5pbmcgdGVzdCBjcnlwdG8gaW4gcmVs
ZWFzZSBtb2RlLi4uCkJsb3dmaXNoLi4uCkFFUy4uLgpNaXNjLi4uClBBU1NFRAooY2QgLi4v
Li4vbGliL2NvbW1vbjsgbWFrZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVh
c2UvbGliL2NvbW1vbi9jb21tb24uYScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9j
b21wcmVzczsgbWFrZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvbGli
L2NvbXByZXNzL2NvbXByZXNzLmEnIGlzIHVwIHRvIGRhdGUuCmAuLi8uLi9yZWxlYXNlL3Rl
c3QvY29tcHJlc3MvdGVzdCcgaXMgdXAgdG8gZGF0ZS4KVEVTVDogdGVzdC9jb21wcmVzcwpS
dW5uaW5nIHRlc3QgY29tcHJlc3MgaW4gcmVsZWFzZSBtb2RlLi4uClBBU1NFRAooY2QgLi4v
Li4vbGliL2NvbW1vbjsgbWFrZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVh
c2UvbGliL2NvbW1vbi9jb21tb24uYScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9z
ZXJ2ZXI7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9z
ZXJ2ZXIvc2VydmVyLmEnIGlzIHVwIHRvIGRhdGUuCmAuLi8uLi9yZWxlYXNlL3Rlc3QvYmFz
aWNzZXJ2ZXIvdGVzdCcgaXMgdXAgdG8gZGF0ZS4KVEVTVDogdGVzdC9iYXNpY3NlcnZlcgpS
ZW1vdmluZyBvbGQgdGVzdCBmaWxlcy4uLgpDb3B5aW5nIG5ldyB0ZXN0IGZpbGVzLi4uClJ1
bm5pbmcgdGVzdCBiYXNpY3NlcnZlciBpbiByZWxlYXNlIG1vZGUuLi4KQ29ubmVjdGVkIHRv
ICdTRVJWRVInCkNvbm5lY3RlZCB0byAnU0VSVkVSJwpDb25uZWN0ZWQgdG8gJ1NFUlZFUicK
c3RyZWFtIGlzIGZpeGVkIHNpemUKc3RyZWFtIGlzIHVuY2VydGFpbiBzaXplCnN0cmVhbSBp
cyBmaXhlZCBzaXplCnN0cmVhbSBpcyB1bmNlcnRhaW4gc2l6ZQpQQVNTRUQKKGNkIC4uLy4u
L2xpYi9jb21tb247IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNl
L2xpYi9jb21tb24vY29tbW9uLmEnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8uLi9saWIvcmFp
ZGZpbGU7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9y
YWlkZmlsZS9yYWlkZmlsZS5hJyBpcyB1cCB0byBkYXRlLgpgLi4vLi4vcmVsZWFzZS90ZXN0
L3JhaWRmaWxlL3Rlc3QnIGlzIHVwIHRvIGRhdGUuClRFU1Q6IHRlc3QvcmFpZGZpbGUKUmVt
b3Zpbmcgb2xkIHRlc3QgZmlsZXMuLi4KQ29weWluZyBuZXcgdGVzdCBmaWxlcy4uLgpSdW5u
aW5nIHRlc3QgcmFpZGZpbGUgaW4gcmVsZWFzZSBtb2RlLi4uClBBU1NFRAooY2QgLi4vLi4v
bGliL2NvbW1vbjsgbWFrZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2Uv
bGliL2NvbW1vbi9jb21tb24uYScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9jb21w
cmVzczsgbWFrZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvbGliL2Nv
bXByZXNzL2NvbXByZXNzLmEnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8uLi9saWIvY3J5cHRv
OyBtYWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9saWIvY3J5cHRv
L2NyeXB0by5hJyBpcyB1cCB0byBkYXRlLgooY2QgLi4vLi4vbGliL3NlcnZlcjsgbWFrZSAt
RCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvbGliL3NlcnZlci9zZXJ2ZXIu
YScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9iYWNrdXBjbGllbnQ7IG1ha2UgLUQg
UkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9iYWNrdXBjbGllbnQvYmFj
a3VwY2xpZW50LmEnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8uLi9saWIvcmFpZGZpbGU7IG1h
a2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9yYWlkZmlsZS9y
YWlkZmlsZS5hJyBpcyB1cCB0byBkYXRlLgooY2QgLi4vLi4vbGliL2JhY2t1cHN0b3JlOyBt
YWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9saWIvYmFja3Vwc3Rv
cmUvYmFja3Vwc3RvcmUuYScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2Jpbi9iYnN0b3Jl
YWNjb3VudHM7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2Jp
bi9iYnN0b3JlYWNjb3VudHMvYmJzdG9yZWFjY291bnRzJyBpcyB1cCB0byBkYXRlLgooY2Qg
Li4vLi4vYmluL2Jic3RvcmVkOyBtYWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4v
cmVsZWFzZS9iaW4vYmJzdG9yZWQvYmJzdG9yZWQnIGlzIHVwIHRvIGRhdGUuCmAuLi8uLi9y
ZWxlYXNlL3Rlc3QvYmFja3Vwc3RvcmUvdGVzdCcgaXMgdXAgdG8gZGF0ZS4KVEVTVDogdGVz
dC9iYWNrdXBzdG9yZQpSZW1vdmluZyBvbGQgdGVzdCBmaWxlcy4uLgpDb3B5aW5nIG5ldyB0
ZXN0IGZpbGVzLi4uClJ1bm5pbmcgdGVzdCBiYWNrdXBzdG9yZSBpbiByZWxlYXNlIG1vZGUu
Li4KU2VydmVyOiAuLi8uLi9iaW4vYmJzdG9yZWQvYmJzdG9yZWQgdGVzdGZpbGVzL2Jic3Rv
cmVkLmNvbmYKRkFJTFVSRTogU2VydmVyIGRpZG4ndCBzYXZlIFBJRCBmaWxlIGF0IC4uLy4u
L2xpYi9jb21tb24vVGVzdC5oKDEzMykKRkFJTFVSRTogQ29uZGl0aW9uIFtwaWQgIT0gLTEg
JiYgcGlkICE9IDBdIGZhaWxlZCBhdCB0ZXN0YmFja3Vwc3RvcmUuY3BwKDE3MDcpCkZBSUxF
RDogMiB0ZXN0cyBmYWlsZWQKKGNkIC4uLy4uL2xpYi9jb21tb247IG1ha2UgLUQgUkVMRUFT
RSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9jb21tb24vY29tbW9uLmEnIGlzIHVw
IHRvIGRhdGUuCihjZCAuLi8uLi9saWIvY29tcHJlc3M7IG1ha2UgLUQgUkVMRUFTRSAtRCBO
T0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9jb21wcmVzcy9jb21wcmVzcy5hJyBpcyB1cCB0
byBkYXRlLgooY2QgLi4vLi4vbGliL2NyeXB0bzsgbWFrZSAtRCBSRUxFQVNFIC1EIE5PREVQ
UykKYC4uLy4uL3JlbGVhc2UvbGliL2NyeXB0by9jcnlwdG8uYScgaXMgdXAgdG8gZGF0ZS4K
KGNkIC4uLy4uL2xpYi9zZXJ2ZXI7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8u
Li9yZWxlYXNlL2xpYi9zZXJ2ZXIvc2VydmVyLmEnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8u
Li9saWIvYmFja3VwY2xpZW50OyBtYWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4v
cmVsZWFzZS9saWIvYmFja3VwY2xpZW50L2JhY2t1cGNsaWVudC5hJyBpcyB1cCB0byBkYXRl
LgooY2QgLi4vLi4vbGliL3JhaWRmaWxlOyBtYWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpg
Li4vLi4vcmVsZWFzZS9saWIvcmFpZGZpbGUvcmFpZGZpbGUuYScgaXMgdXAgdG8gZGF0ZS4K
KGNkIC4uLy4uL2xpYi9iYWNrdXBzdG9yZTsgbWFrZSAtRCBSRUxFQVNFIC1EIE5PREVQUykK
YC4uLy4uL3JlbGVhc2UvbGliL2JhY2t1cHN0b3JlL2JhY2t1cHN0b3JlLmEnIGlzIHVwIHRv
IGRhdGUuCihjZCAuLi8uLi9iaW4vYmJhY2t1cGQ7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RF
UFMpCmAuLi8uLi9yZWxlYXNlL2Jpbi9iYmFja3VwZC9iYmFja3VwZCcgaXMgdXAgdG8gZGF0
ZS4KKGNkIC4uLy4uL2Jpbi9iYmFja3VwcXVlcnk7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RF
UFMpCmAuLi8uLi9yZWxlYXNlL2Jpbi9iYmFja3VwcXVlcnkvYmJhY2t1cHF1ZXJ5JyBpcyB1
cCB0byBkYXRlLgooY2QgLi4vLi4vYmluL2Jic3RvcmVhY2NvdW50czsgbWFrZSAtRCBSRUxF
QVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvYmluL2Jic3RvcmVhY2NvdW50cy9iYnN0
b3JlYWNjb3VudHMnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8uLi9iaW4vYmJzdG9yZWQ7IG1h
a2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2Jpbi9iYnN0b3JlZC9i
YnN0b3JlZCcgaXMgdXAgdG8gZGF0ZS4KYC4uLy4uL3JlbGVhc2UvdGVzdC9iYWNrdXBzdG9y
ZWZpeC90ZXN0JyBpcyB1cCB0byBkYXRlLgpURVNUOiB0ZXN0L2JhY2t1cHN0b3JlZml4ClJl
bW92aW5nIG9sZCB0ZXN0IGZpbGVzLi4uCkNvcHlpbmcgbmV3IHRlc3QgZmlsZXMuLi4KQWNj
b3VudCAxMjM0NTY3IGNyZWF0ZWQKUnVubmluZyB0ZXN0IGJhY2t1cHN0b3JlZml4IGluIHJl
bGVhc2UgbW9kZS4uLgpTZXJ2ZXI6IC4uLy4uL2Jpbi9iYnN0b3JlZC9iYnN0b3JlZCB0ZXN0
ZmlsZXMvYmJzdG9yZWQuY29uZgpGQUlMVVJFOiBTZXJ2ZXIgZGlkbid0IHNhdmUgUElEIGZp
bGUgYXQgLi4vLi4vbGliL2NvbW1vbi9UZXN0LmgoMTMzKQpGQUlMVVJFOiBDb25kaXRpb24g
W3BpZCAhPSAtMSAmJiBwaWQgIT0gMF0gZmFpbGVkIGF0IHRlc3RiYWNrdXBzdG9yZWZpeC5j
cHAoMzQ3KQpGQUlMRUQ6IDIgdGVzdHMgZmFpbGVkCihjZCAuLi8uLi9saWIvY29tbW9uOyBt
YWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL2Nv
bW1vbi5hJyBpcyB1cCB0byBkYXRlLgooY2QgLi4vLi4vbGliL2NvbXByZXNzOyBtYWtlIC1E
IFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9saWIvY29tcHJlc3MvY29tcHJl
c3MuYScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9jcnlwdG87IG1ha2UgLUQgUkVM
RUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9jcnlwdG8vY3J5cHRvLmEnIGlz
IHVwIHRvIGRhdGUuCihjZCAuLi8uLi9saWIvc2VydmVyOyBtYWtlIC1EIFJFTEVBU0UgLUQg
Tk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9saWIvc2VydmVyL3NlcnZlci5hJyBpcyB1cCB0byBk
YXRlLgooY2QgLi4vLi4vbGliL2JhY2t1cGNsaWVudDsgbWFrZSAtRCBSRUxFQVNFIC1EIE5P
REVQUykKYC4uLy4uL3JlbGVhc2UvbGliL2JhY2t1cGNsaWVudC9iYWNrdXBjbGllbnQuYScg
aXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9yYWlkZmlsZTsgbWFrZSAtRCBSRUxFQVNF
IC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvbGliL3JhaWRmaWxlL3JhaWRmaWxlLmEnIGlz
IHVwIHRvIGRhdGUuCihjZCAuLi8uLi9saWIvYmFja3Vwc3RvcmU7IG1ha2UgLUQgUkVMRUFT
RSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9iYWNrdXBzdG9yZS9iYWNrdXBzdG9y
ZS5hJyBpcyB1cCB0byBkYXRlLgooY2QgLi4vLi4vYmluL2Jic3RvcmVhY2NvdW50czsgbWFr
ZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvYmluL2Jic3RvcmVhY2Nv
dW50cy9iYnN0b3JlYWNjb3VudHMnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8uLi9iaW4vYmJz
dG9yZWQ7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2Jpbi9i
YnN0b3JlZC9iYnN0b3JlZCcgaXMgdXAgdG8gZGF0ZS4KYC4uLy4uL3JlbGVhc2UvdGVzdC9i
YWNrdXBzdG9yZXBhdGNoL3Rlc3QnIGlzIHVwIHRvIGRhdGUuClRFU1Q6IHRlc3QvYmFja3Vw
c3RvcmVwYXRjaApBY2NvdW50IDEyMzQ1NjcgY3JlYXRlZApSdW5uaW5nIHRlc3QgYmFja3Vw
c3RvcmVwYXRjaCBpbiByZWxlYXNlIG1vZGUuLi4KU2VydmVyOiAuLi8uLi9iaW4vYmJzdG9y
ZWQvYmJzdG9yZWQgdGVzdGZpbGVzL2Jic3RvcmVkLmNvbmYKRkFJTFVSRTogU2VydmVyIGRp
ZG4ndCBzYXZlIFBJRCBmaWxlIGF0IC4uLy4uL2xpYi9jb21tb24vVGVzdC5oKDEzMykKRkFJ
TFVSRTogQ29uZGl0aW9uIFtwaWQgIT0gLTEgJiYgcGlkICE9IDBdIGZhaWxlZCBhdCB0ZXN0
YmFja3Vwc3RvcmVwYXRjaC5jcHAoMzYyKQpGQUlMRUQ6IDIgdGVzdHMgZmFpbGVkCihjZCAu
Li8uLi9saWIvY29tbW9uOyBtYWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVs
ZWFzZS9saWIvY29tbW9uL2NvbW1vbi5hJyBpcyB1cCB0byBkYXRlLgooY2QgLi4vLi4vbGli
L2NvbXByZXNzOyBtYWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9s
aWIvY29tcHJlc3MvY29tcHJlc3MuYScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9j
cnlwdG87IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9j
cnlwdG8vY3J5cHRvLmEnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8uLi9saWIvc2VydmVyOyBt
YWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9saWIvc2VydmVyL3Nl
cnZlci5hJyBpcyB1cCB0byBkYXRlLgooY2QgLi4vLi4vbGliL2JhY2t1cGNsaWVudDsgbWFr
ZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvbGliL2JhY2t1cGNsaWVu
dC9iYWNrdXBjbGllbnQuYScgaXMgdXAgdG8gZGF0ZS4KYC4uLy4uL3JlbGVhc2UvdGVzdC9i
YWNrdXBkaWZmL3Rlc3QnIGlzIHVwIHRvIGRhdGUuClRFU1Q6IHRlc3QvYmFja3VwZGlmZgpS
dW5uaW5nIHRlc3QgYmFja3VwZGlmZiBpbiByZWxlYXNlIG1vZGUuLi4KUEFTU0VECihjZCAu
Li8uLi9saWIvY29tbW9uOyBtYWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVs
ZWFzZS9saWIvY29tbW9uL2NvbW1vbi5hJyBpcyB1cCB0byBkYXRlLgooY2QgLi4vLi4vbGli
L2NvbXByZXNzOyBtYWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9s
aWIvY29tcHJlc3MvY29tcHJlc3MuYScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9j
cnlwdG87IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9j
cnlwdG8vY3J5cHRvLmEnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8uLi9saWIvc2VydmVyOyBt
YWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9saWIvc2VydmVyL3Nl
cnZlci5hJyBpcyB1cCB0byBkYXRlLgooY2QgLi4vLi4vbGliL2JhY2t1cGNsaWVudDsgbWFr
ZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvbGliL2JhY2t1cGNsaWVu
dC9iYWNrdXBjbGllbnQuYScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4uLy4uL2xpYi9yYWlkZmls
ZTsgbWFrZSAtRCBSRUxFQVNFIC1EIE5PREVQUykKYC4uLy4uL3JlbGVhc2UvbGliL3JhaWRm
aWxlL3JhaWRmaWxlLmEnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8uLi9saWIvYmFja3Vwc3Rv
cmU7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2xpYi9iYWNr
dXBzdG9yZS9iYWNrdXBzdG9yZS5hJyBpcyB1cCB0byBkYXRlLgooY2QgLi4vLi4vYmluL2Ji
YWNrdXBjdGw7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAuLi8uLi9yZWxlYXNlL2Jp
bi9iYmFja3VwY3RsL2JiYWNrdXBjdGwnIGlzIHVwIHRvIGRhdGUuCihjZCAuLi8uLi9iaW4v
YmJhY2t1cHF1ZXJ5OyBtYWtlIC1EIFJFTEVBU0UgLUQgTk9ERVBTKQpgLi4vLi4vcmVsZWFz
ZS9iaW4vYmJhY2t1cHF1ZXJ5L2JiYWNrdXBxdWVyeScgaXMgdXAgdG8gZGF0ZS4KKGNkIC4u
Ly4uL2Jpbi9iYnN0b3JlYWNjb3VudHM7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RFUFMpCmAu
Li8uLi9yZWxlYXNlL2Jpbi9iYnN0b3JlYWNjb3VudHMvYmJzdG9yZWFjY291bnRzJyBpcyB1
cCB0byBkYXRlLgooY2QgLi4vLi4vYmluL2Jic3RvcmVkOyBtYWtlIC1EIFJFTEVBU0UgLUQg
Tk9ERVBTKQpgLi4vLi4vcmVsZWFzZS9iaW4vYmJzdG9yZWQvYmJzdG9yZWQnIGlzIHVwIHRv
IGRhdGUuCihjZCAuLi8uLi9iaW4vYmJhY2t1cGQ7IG1ha2UgLUQgUkVMRUFTRSAtRCBOT0RF
UFMpCmAuLi8uLi9yZWxlYXNlL2Jpbi9iYmFja3VwZC9iYmFja3VwZCcgaXMgdXAgdG8gZGF0
ZS4KYC4uLy4uL3JlbGVhc2UvdGVzdC9iYmFja3VwZC90ZXN0JyBpcyB1cCB0byBkYXRlLgpU
RVNUOiB0ZXN0L2JiYWNrdXBkClJlbW92aW5nIG9sZCB0ZXN0IGZpbGVzLi4uCkNvcHlpbmcg
bmV3IHRlc3QgZmlsZXMuLi4KQWNjb3VudCAxMjM0NTY3IGNyZWF0ZWQKUnVubmluZyB0ZXN0
IGJiYWNrdXBkIGluIHJlbGVhc2UgbW9kZS4uLgpTZXJ2ZXI6IC4uLy4uL2Jpbi9iYnN0b3Jl
ZC9iYnN0b3JlZCB0ZXN0ZmlsZXMvYmJzdG9yZWQuY29uZgpGQUlMVVJFOiBTZXJ2ZXIgZGlk
bid0IHNhdmUgUElEIGZpbGUgYXQgLi4vLi4vbGliL2NvbW1vbi9UZXN0LmgoMTMzKQpGQUlM
VVJFOiBDb25kaXRpb24gW2Jic3RvcmVkX3BpZCAhPSAtMSAmJiBiYnN0b3JlZF9waWQgIT0g
MF0gZmFpbGVkIGF0IHRlc3RiYmFja3VwZC5jcHAoMTk4KQpGQUlMRUQ6IDIgdGVzdHMgZmFp
bGVkCi0tLS0tLS0tCmNvbW1vbjogUEFTU0VECmNyeXB0bzogUEFTU0VECmNvbXByZXNzOiBQ
QVNTRUQKYmFzaWNzZXJ2ZXI6IFBBU1NFRApyYWlkZmlsZTogUEFTU0VECmJhY2t1cHN0b3Jl
OiBGQUlMRUQ6IDIgdGVzdHMgZmFpbGVkCmJhY2t1cHN0b3JlZml4OiBGQUlMRUQ6IDIgdGVz
dHMgZmFpbGVkCmJhY2t1cHN0b3JlcGF0Y2g6IEZBSUxFRDogMiB0ZXN0cyBmYWlsZWQKYmFj
a3VwZGlmZjogUEFTU0VECmJiYWNrdXBkOiBGQUlMRUQ6IDIgdGVzdHMgZmFpbGVkCg==

-------ddf93f2a4541ede035ce6ca3ec9f95ce--


From boxbackup at fluffy.co.uk  Mon Oct 31 16:51:12 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Mon, 31 Oct 2005 16:51:12 +0000
Subject: [Box Backup] failed tests from "make test" in obsd 3.8-current
In-Reply-To: <8c6959fa.53f4d953.8203000@m4500-00.uchicago.edu>
References: <8c6959fa.53f4d953.8203000@m4500-00.uchicago.edu>
Message-ID: <745DB99D-D238-4E0A-B692-9B2981C659C8@fluffy.co.uk>

On 31 Oct 2005, at 16:45, <dick at uchicago.edu> wrote:

> heya,
>
> i'm compiling boxbackup-0.09 and i have no problems
> configuring and making, but when i run the "make test" i
> notice that it fails a number of these tests. i'm running
> openbsd 3.8-current on a machine that will soon run
> 3.8-release and has a hardware RAID 1 array (2x200GB). here is
> the output of the failed tests:
>
> common: PASSED
> crypto: PASSED
> compress: PASSED
> basicserver: PASSED
> raidfile: PASSED
> backupstore: FAILED: 2 tests failed
> backupstorefix: FAILED: 2 tests failed
> backupstorepatch: FAILED: 2 tests failed
> backupdiff: PASSED
> bbackupd: FAILED: 2 tests failed
>
> i've attached the full output of the "make test", in case that
> holds additional useful information. i can send along a dmesg
> if that would help.

Looks like a timing issue. (The tests are a fine balance between  
running in a sensible time and reliably passing. Remember they're  
testing a separate daemon which does things in it's own sweet time.)  
Because of this, backupstore left the server running, which stopped  
future daemon based tests working.

Basically, it's fine. Not an ideal answer, I know. The test suite  
does need revisiting at some point.

Ben





From boxbackup at fluffy.co.uk  Mon Oct 31 17:47:57 2005
From: boxbackup at fluffy.co.uk (boxbackup at fluffy.co.uk)
Date: Mon, 31 Oct 2005 11:47:57 -0600
Subject: [Box Backup] failed tests from "make
 test" in obsd 3.8-current
Message-ID: <6c2ab9a3.53fa93bb.81b3f00@m4500-00.uchicago.edu>

ben,

>
>Looks like a timing issue. (The tests are a fine balance
between  
>running in a sensible time and reliably passing. Remember
they're  
>testing a separate daemon which does things in it's own sweet
time.)  
>Because of this, backupstore left the server running, which
stopped  
>future daemon based tests working.
>
>Basically, it's fine. Not an ideal answer, I know. The test
suite  
>does need revisiting at some point.

thanks for the snappy reply. i'll make sure to test everything
before i rely on it for backups. good to hear that that all is
working :).

regards,
jake


From boxbackup at fluffy.co.uk  Mon Oct 31 18:25:56 2005
From: boxbackup at fluffy.co.uk (Ben Summers)
Date: Mon, 31 Oct 2005 18:25:56 +0000
Subject: [Box Backup] Code in SVN -- review notes
Message-ID: <7CCBDC4F-90F9-4683-A38E-39BFBD7E3E1D@fluffy.co.uk>

I've taken a look at the code checked in recently, notes below. Does  
anyone else feel like reviewing the code?

Generally, it's almost ready to merge in, and some handy stuff to  
have. But the Win32 ports needs more attention as it's rather more  
complex. Especially wrt to the build environment.

Thanks for all the efforts of the contributors. I notice none of you  
have bothered adding a decent CONTRIBUTORS file, this must be rectified.

Ben



martin/solaris
==============
lib/server/Protocol.cpp -- can we avoid those extra memcpys? Is it  
actually causing a problem with some processor without the ability to  
do non-word aligned loads? Can we make it conditional on being run on  
one of those processors using PLATFORM_ALIGN_INT?

Otherwise all good.


martin/ppcfixes
===============
All good.


martin/xattr
============
xattr is also available on Darwin, so the name of the test is  
probably misleading.

My worries is that there may be quite a bit of xattr data, and the  
way BackupClientFileAttributes are used assumes that they are  
relatively small. I think they would be better represented as a  
stream. But then, we need to write the code to support multiple streams.

Under Darwin, it'll pick up the resource fork as an xattr. This could  
be quite large!

A minor point, but in the format of the structure, you would have to  
store a zero for the xattr size if it was extended afterwards. Also  
if it was stored here, perhaps I would prefer the ability to stack  
multiple attribute records, so you'd get a standard UNIX one and  
another xattr one?

I would be happy for this to be committed, as long as there was a  
commitment (!) to revisit this code when multiple streams are  
available in backup files.

(I'm quite keen on getting xattr's done properly. Another project of  
mine [ http://www.fluffy.co.uk/spotmeta/ ] uses them quite extensively!)


martin/autoconf
===============
You appear to have removed my code which means someone has to take  
positive action to working with old versions of OpenSSL. I'd prefer  
that stayed -- it's a nasty hack to do the stuff I need with older  
OpenSSLs.

infrastructure/BoxPlatform.pm - license slipped in!

I think it looks OK (reading the diffs carefully) but I'm not sure  
how to actually compile it. We need to try it out on "all" platforms.

Also, how do we go about making a distribution? It'd be nice to have  
something in docs/.


chromi/diffopt
==============
static int sMaximumDiffTime = 600;             // maximum time to  
spend diffing
     -- not sure whether this is good or not?

Style: A tendency to place {'s on the same line as ifs and whiles.  
And "} else {"...

Is docs/backup/encrypt_rsync.txt changed, or just renamed? Use svn  
rename first anyway.

Looks good, these are very minor points. But I would appreciate  
consistent style.


nick/win
========
To be honest, this scares me. Also, the DOS line endings screw up the  
diffs. Something to look at in more detail another day, I'm afraid.  
If someone would like to commit one with the line endings The  
Invisible Sky Giant intended us to use, that would be lovely.