Hello John,
Tested svnup for a while, and I can say it does its job well, and works
basically as I would expect, so thanks for your initiative. Although it
appears to be quite resource greedy. Most of the time it showed
something like:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
22270 mkushnir 1 102 0 44944K 31804K CPU0 1 6:22 97.56% a.out
I looked at the source code, and found that it uses svn commands that
are known as the "main command set". The program is implemented around
get-dir and get-file. I think there is significant room for resource and
performance improvement.
Have you considered an approach to use what svn folks call the editor
command set? I mean acting as a trivial svn client: we might ask the
server to drive our checking out or updating. The server will be telling
us only diffs. Checking out a full tree would be just another diff,
although bigger than usually. We would also benefit from compression on
the wire.
Another advantage would be to always have consistent repo more-or-less
guaranteed by the svn server.
I've done some proof of concept recently, and the results look
encouraging to me. For example, a do-nothing update really does nothing.
A two-or-three revisions update takes a couple of seconds. And a full
checkout of the base/stable/9 takes ~7m30s at 530kB/s to me.
--
Markiyan.
On 14.03.2013 04:30, John Mehr wrote:
On Wed, 13 Mar 2013 14:50:43 -0400
"David Magda" <dma...@ee.ryerson.ca> wrote:
On Tue, March 12, 2013 19:32, John Mehr wrote:
This sounds good to me, and as long as there's some sort
of a consensus that we're not breaking the principle of
least surprise, I'm all for it. The one default that may
be unexpected is the defaulting to the stable branch --
people who track the security branches will be left out.
So maybe something like:
svnup --ports
svnup --stable
svnup --security (or --release)
Thoughts?
If svnup will eventually going to be used to update a variety of
repositories, on a plethora of operating systems, then hard coding the
above may not be appropriate. Something akin to "svnup --repo={ports,
stable, security, release}" may be better, and then have a configuration
file with the settings.
Hello,
You're absolutely correct. It looks like someone has already forked the
code on github which seems like pretty solid evidence for taking as
flexible an approach as possible and minimizing the amount of hard coded
data.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
