Hi Mark,
> I have to add that I am using a satellite based ISP that while
> higher speed than dialup, limits the amount of data I can download
> (to 200 MB per day) except between 3am and 6am. I know this is not
> ideal, but traditional high speed choices aren't available to me.
200MB isn't too little, unless you also have to download other stuff too. A usual update size is
about a few MB at most. HOWEVER, when there are changes to 3rd-party binaries, the update size can
go up quite a bit. Updating is usually not problematic (unless it gets disrupted, and the update
size is huge). It's the initial checking out that can kill you.
Even with high internet speeds, the http protocol for downloading via SVN can sometimes be
disrupted (and you have to start all over again). We have OFBiz students here in Singapore who
complain that they simply can't complete a checkout of OFBiz (we have high speed broadband). So,
we actually had to send them a tarball of a pre- checked out OFBiz (including .svn files). As I
said, updating (not checking out fresh) usually is fine.
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.
Maybe this wasn't taken up because I didn't completely describe my recommended solution. So, here
goes!
1. Check out the latest OFBiz
2. Create an MD5 signature of all 3rd-party binaries.
3. Take out all those binaries.
4. Commit the MD5 signature.
5. Bundle those binaries into a tarball to be downloaded separately,
outside of SVN.
6. Create script to deploy those binaries back into OFBiz file
structure.
7. Commit that script.
Something like that.
Even the 4+MB Dojo can be packaged separately, rather than stuffed into the SVN! That'll be about
40+MB less to download from SVN (http protocol)!
I've done that umpteen times already, so if the OFBiz team wants me to actually do it for them,
I'd be glad to help.
David Jones recently mentioned "drop-in or add-in components". That is a sweet ideal. Shouldn't we
attempt to component-ize OFBiz then? That way, we can drop in Dojo or Prototype, Log4J version x
or Log4J version y, etc.
If anyone wants to know how MD5 signatures can help in both decentralized software development
teams and in legal documents, maybe read up on MD5 in wikipedia or something.
Jonathon
Mark Erbaugh wrote:
On Fri, 2007-09-14 at 01:50 -0600, David E Jones wrote:
It has been nearly 5 months since we created the release4.0 branch (late
April). The hope for these release branches is that they will stabilize within
about 3 months and be ready for an initial binary release. In order for this to
happen effectively each branch needs a reasonably sized subset of the OFBiz
community doing real-world work based on it. So...
1. Are there any users of the release4.0 branch with projects in production or
moving in that direction?
2. For anyone in that group, could you share your thoughts on the current state
of the branch?
At the minute the initial binary release has been delayed because committers
and the PMC have been very busy on other projects (quite a summer!), but mostly
because there just don't seem to be many issues files specifically for
release4.0 and because there hasn't been much feedback from users grouping
around that branch. Hence this email...
Because of the passing of time we will release a binary version in the near
future (perhaps a couple of weeks or so) regardless of the responses in this
thread or other relevant threads. If nothing else that may help attract
end-users to the branch.
What is the procedure for working with a release branch? I used
Subclipse (in Eclipse) to checkout the release 4 branch and I have been
working with a local copy thinking that the branch was frozen. The
comments above sound like it is not.
At this point, I'm trying to learn OfBiz and wanted to get a (more)
solid footing before the code started changing underneath me.
This question also goes to my lack of familiarity with Subversion. So
far, I've only used it to track my own projects. Right now, what I did
was checkout the release 4 branch. I then disconnected the project from
the repository and re-created a project in my local repository. That
way, as I'm learning, I can try code changes to see what happens, and
still revert pieces.
I have to add that I am using a satellite based ISP that while higher
speed than dialup, limits the amount of data I can download (to 200 MB
per day) except between 3am and 6am. I know this is not ideal, but
traditional high speed choices aren't available to me.
So I checked out the project early one morning and have been working
with the local copy. Is there a way with Subclipse (or Subversion) to
tell how much data needs to be transferred to sync up?
Mark
