> You either manually manage it
There's nothing for users or downloaders to manage. If there's a problem with doing a complete SVN
checkout, there's nothing to manage in the first place! No OFBiz SVN workspace to begin with!
It's also tough for someone who has somehow lost his OFBiz SVN workspace, and has to SVN co the
whole thing again.
> or let a system do it.
What kind of system will:
1. Speed up SVN over http (before it times out), OR
2. Prevent a SVN co from being disrupted, OR
3. Resume a disrupted SVN co?
I'd like to know. That kind of system will really help a lot!
> Manual things cause huge problems for complex systems.
The deployment script (that deploys binaries into OFBiz file structure) isn't complex at all. It's
nowhere near Redhat's RPM, Debian's apt-get, etc!
As for verifying that OFBiz workspace has all necessary binaries, the single MD5 manifest can
easily be processed with a single click (or even as part of the deployment script). And that will
tell the developer exactly which binaries are missing or different from expected.
So, the process for a new user is:
1. Download SVN.
2. SVN checkout OFBiz.
3. Download libraries (binaries).
4. Click to install libraries (and to verify).
5. Configure OFBiz.
6. Install OFBiz (run-install)
7. Start OFBiz.
Note how only 2 of the 7 steps are extra.
Currently, many users (including some of my clients) can't even get past step 2! Many won't even
consider step 1, to begin with.
> The extra effort require to normally do it is a small issue, the huge time
> wasting caused by small errors in these manual processes makes them worth all
> the effort and downside necessary to avoid them.
Well, apt-get isn't so difficult to use, right? And the deploy/clean scripts I am talking about is
nowhere near as difficult to develop as apt-get!
> I totally agree with David, really easier for us.
But have you tried doing things in another way, so you know for sure that other way doesn't work
for you?
Anyway, if you're happy with the current setup, I rest my case.
Jonathon
Jacques Le Roux wrote:
I totally agree with David, really easier for us.
Jacques
De : "David E Jones" <[EMAIL PROTECTED]>
Jonathon -- Improov wrote:
For some time now, I had been suggesting that we DO NOT include the
35+MB binaries in the SVN. SVN is used to track CHANGES to files. Since
we cannot change binaries (only source codes), binaries have no business
residing in SVN. In fact, a guy who claimed he knows SVN, but who later
proceeded to check in version after version of his project binaries, got
fired. Yeah, it's that scary to see someone use version control app to
maintain software binaries (pic binaries are fine).
There's this argument put forth that "it's more convenient if we bundle
the binaries in, so that new users can get up to speed quickly".
However, new users who bother to use SVN should already be quite
technically inclined, and will be able to run a script to "install"
3rd-party binaries into a deployment.
As it is now, with the 35+MB (or more?) binaries in SVN, it simply makes
it somewhat harder even for experienced SVN or OFBiz users to download
OFBiz.
This really isn't so much for new users, it's for all users of OFBiz, and IMO
mostly for the regular and highly involved users.
You either manually manage it or let a system do it. There is no way, period,
I'd personally go for this because it would cause
significant problems without any real upside for 99% of OFBiz users and
developers, most importantly the contributing developers
that SVN is meant for.
Manual things cause huge problems for complex systems. The extra effort require
to normally do it is a small issue, the huge time
wasting caused by small errors in these manual processes makes them worth all
the effort and downside necessary to avoid them.
-David
