RE: Barracuda: Moving the src directory

Hi Jake,

> Don't we lose all the history by moving the directory?  That
> wouldn't be a good thing to happen.  If we can do it without

Nope. We can do it without losing any history. Shawn's already tested it out
to verify.

> directory exists.  However, doesn't this limit the documentation
> when linking to the relevant sourcecode?  You can't link to

Yeah, that would be a drawback, although probably not a real major one. We
could always link to the source through the cvsweb interface, so it'd still
be there. Or we could copy the text up to the docs directories if need be.
Let me think about it...

> Sounds fine, although you'll still have a problem with the <copy>
> of the jar files from the lib-cvs to lib because if the file
> dates on the files in lib are newer than those obtained via cvs,
> they won't be copied over....or maybe that is a good thing if the
> files in lib contain updates that don't exist in cvs?  Well,

The basic idea is that the files never get copied over unless the dates are
newer (which they would be if you rebuild the jars and update cvs).

> Well, either way, I don't like the idea of storing non-third-party
> libraries in cvs.  I can see where people might like the idea of
> being able to obtain the libs without having to perform a build,
> but that is really what nightly builds are for.

The biggest reason for doing it this way is so that you can tag a particular
version of cvs and then check out based on that tag, and know that you have
a running version of the system without having to do a compile. Which makes
it reeeeeeally easy to update the version on the server. Otherwise you end
up with a situation where you go to update the server, it does a
clean/rebuild and something breaks, and now you have to figure out how to
recover.

> it brings up this whole issue
> of the cvs "update" failing because it can't delete libs that are
> stored in cvs and locked by the server.

Actually, by using a lib-cvs approach, the jar files that are under cvs are
never actually locked, so it really isn't a problem.

We can figure out all the details as we go forward, but for now I just
wanted to answer some of your basic questions.

Christian
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Jacob Kjome
> Sent: Sunday, December 08, 2002 2:40 PM
> To: [email protected]
> Subject: Re: Barracuda: Moving the src directory
>
>
>
> Hi Christian,
>
> See comments below...
>
> At 04:54 PM 12/7/2002 -0500, you wrote:
>
> Hey folks, as we get ready to move things over to the BarracudaMVC server,
> we're going to be doing some much needed housecleaning. One of the things
> I'd like to do is move the src directory down underneath WEB-INF. It was
> orginally placed up in the content directory so that people could
> browse it
> online, but since the online cvs interface does a much better job of
> handling that anyway, I'd like to move it down underneath WEB-INF. Does
> anyone object to that?
>
>
> Don't we lose all the history by moving the directory?  That
> wouldn't be a good thing to happen.  If we can do it without
> losing the history, I really don't much care where the src
> directory exists.  However, doesn't this limit the documentation
> when linking to the relevant sourcecode?  You can't link to
> anything existing beneath WEB-INF unless you front the webapp
> with Another web server and don't enforce not being able to see
> under WEB-INF.  And doing such a thing is not good practice
> anyway.  I'm just wondering what the real benefits from moving
> the src directory are?
>
>
> Also, I'd like to move the build.xml stuff and the .bat files out
> of the src
> directory and into WEB-INF/bin, if nobody objects. The idea would be then
> that you'd go to WEB-INF/bin to build the system.
>
>
> There is probably no issue with this except for the concerns I
> already outlined above.  Actually, if we are going to move things
> around, we might want to create a "source" directory and then
> beneath that have stuff like "bin", "java", "javascript", etc....
> just to demarcate the different types of source that we have
> instead of lumping it all in to one java-centric package structure.
>
>
> Finally, one additional change will be to create a WEB-INF/lib-cvs
> directory, and to place all the jars that are under cvs in here,
> rather than
> in WEB-INF/lib. There would still be jars in the lib directory, but they
> won't be under cvs. The reason for doing this is so that you can
> update your
> Barracuda installs from cvs _without_ having to shut down Tomcat (when cvs
> updates, it tries to delete files before replacing them, and it can't do
> that to files in /lib because Tomcat has them locked). So the way it works
> then is you a) update from cvs and b) install (which copies jars from
> WEB-INF/lib-cvs to WEB-INF/lib. We've been using this strategy for about 4
> mths now here at ATMReports, and its worked quite well.
>
>
> Sounds fine, although you'll still have a problem with the <copy>
> of the jar files from the lib-cvs to lib because if the file
> dates on the files in lib are newer than those obtained via cvs,
> they won't be copied over....or maybe that is a good thing if the
> files in lib contain updates that don't exist in cvs?  Well,
> either way, I don't like the idea of storing non-third-party
> libraries in cvs.  I can see where people might like the idea of
> being able to obtain the libs without having to perform a build,
> but that is really what nightly builds are for.  If we diligently
> produced nightly builds, then storing the jars in cvs becomes
> truly pointless.  It both unnecessarily increases the time to do
> a "checkout" of the latest cvs and it brings up this whole issue
> of the cvs "update" failing because it can't delete libs that are
> stored in cvs and locked by the server.  There is no reason this
> issue should exist.  I say lets completely get rid of any
> Barracuda-built jars from storage in cvs.
>
>
> If anyone has any comments on this, please speak up! I'm not planning on
> making these changes in existing cvs tree, but would put them in place on
> the new server.
>
>
> Let me know what you think.
>
> Jake
>
>
>
> Christian
> ----------------------------------------------
> Christian Cryder [[email protected]]
> Internet Architect, ATMReports.com
> Barracuda - http://barracuda.enhydra.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
>
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://www.enhydra.org/mailman/listinfo.cgi/barracuda
> FAQ - http://www.jguru.com/faq/Barracuda

_______________________________________________
Barracuda mailing list
[email protected]
http://www.enhydra.org/mailman/listinfo.cgi/barracuda
FAQ - http://www.jguru.com/faq/Barracuda