Davis,
Just to let you know we have been using subversion for our embedded
devices for the past year. We run an embedded linux system based on
uclibc and busybox. Initially we used rsync against and svn working copy
of our image, using asvn to generate a full filesystem image.
A few months back we wrote our own svn read only client which allows our
devices to update directly from the svn repository. Our client supports
the property settings used by asvn plus it operates without a text base
copy. We also have near atomic checkouts, this was very important to us
as a failure part way though an update could have left the system
un-recoverable.
We don't use keyword expansion in our files so there is no need for the
text-base files. Also we ensure all files are of the one revision.
Updates are performed into a new directory using the original files as
the working text-base. All deletions are stored as commands for post
processing. Once all the updates have finished we then rename all the
files/directories in the new download area into our working system,
processing any deletions, and update the global revision number. This is
why we say our updates are near atomic as there is a small period
between when the files are being renamed and the global revision number
is updated that we are a mixed version. To cater for reboots during this
period our boot procedure runs a cleanup process that checks for any un
applied updates.
We already had the frame work in place to trigger remote upgrades of our
devices.
FYI it took our engineer about 2 wks to finish the application to a
stage we could deploy it. It supports checkouts/updates/switch to any
given revision of the repository. We did use neon/openssl for the comms.
Ross
Davis Ford wrote:
>Hi,
>
>I have a couple of questions. I am thinking of a usage scenario for
>Subversion, and I want to pass it through the group here to get
>technical opinion on whether it seems reasonable.
>
>Perhaps this has been done before, and I would appreciate anyone with
>this type of scenario to provide lessons-learned.
>
>I would like to deploy subversion as a remote management solution for
>embedded devices out in the field. It would essentially work like
>this:
>
>1) Create embedded file system with directory structure and binaries
>on remote host (back end server).
>
>2) Send a command to embedded client device to do a checkout from this
>back end server.
>
>3) Embedded client device contacts server over HTTPS and checks out
>majority of it's file-system with all binaries, etc. This requires a
>small framework to pre-exist on the embedded client. It must have (at
>minimum):
> a) RTOS
> b) SVN Client
> c) Comm Stack and the ability to receive remote commands that can
>be translated into SVN client commands
> d) Pre-existing file system directory structure equal to back
>office -- the checkout simply fills a lot of the stuff into the
>directories (binaries, conf files).
>
>4) Now, if you want to make a change, you can drop a new binary into
>the filesystem on the Server side, and send a command to the remote
>client to do an update. This requires a framework be in place such
>that after the update is made, the system knows how to deal with the
>change. This is software that will have to be written, of course.
>
>Questions I have:
>
>a) How portable is the SVN command line client code to other
>architectures (e.g. PPC, ARM)?
>b) What is the protocol overhead that SVN imposes? Aside from
>TCP/IP/HTTPS, and the payload, what is the SVN protocol overhead?
>c) What is the robustness of SVN over WAN communication links that are
>unreliable? Has the system been constructed to deal with network
>failures in the middle of an update/checkout? I realize there are DB
>utilities to fix these things on the server side...and there is SVN
>cleanup on the client side. We need to expect that this can be a
>common scenario (lose connectivity in the middle), and I want to
>understand if there is a solid mechanism to recover from it that is
>robust.
>d) What is the file system overhead of the .svn directories?
>
>Thanks in advance for any feedback!
>
>Regards,
>Davis
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 7 01:02:45 2005