svn checkout strategies

[Paul G. Weiss]

I see the following choices:

1. Use 'svn update' as much as possible.
2. Use 'svn update' as much as possible, with 'svn revert' before update.
3. Emulate clean checkout by first deleting unversioned/ignored files,
then 'svn update'.
4. Always check out a fresh copy.

At first glance these strategies seem increasingly more conservative, but
in fact (2) and (3) are incomparable.

Strategy (2) will make sure that any versioned files that were modifying
are restored, but will leave unversioned or ignored files in place.
Stragegy (3) will remove unversioned/ignored files but does nothing about
modified versioned files.

Should strategy (3) instead be:

3a. Emulate clean checkout by first deleting unversioned/ignored files,
then 'svn revert', then 'svn update'.

or is this intentional.

-P

[Messmer, Jason]

Does anyone know how to setup views like the ones located on the
Apache Jenkins https://builds.apache.org/hudson/ site?

Thanks,
Jay

[Gandhi, Pawan]

I think they used http://wiki.jenkins-ci.org/display/JENKINS/Nested+View+Plugin

[Messmer, Jason]

I figured it out... A nested view with List views and then setting the nested view with a default subview...

-----Original Message-----
From: jenkins...@googlegroups.com [mailto:jenkins...@googlegroups.com] On Behalf Of Messmer, Jason
Sent: Tuesday, March 29, 2011 10:31 AM
To: jenkins...@googlegroups.com
Subject: How to setup a views like on the https://builds.apache.org/hudson/ site

[Vincent Hardion]

Can you precise your thought ?

Regards,
Vincent

[David Weintraub]

On Tue, Mar 29, 2011 at 9:34 AM, Paul G. Weiss <pa...@weiss.name> wrote:
> I see the following choices:
>
> 1. Use 'svn update' as much as possible.
> 2. Use 'svn update' as much as possible, with 'svn revert' before update.
> 3. Emulate clean checkout by first deleting unversioned/ignored files, then
> 'svn update'.
> 4. Always check out a fresh copy.

We normally only do an update, then run the "clean" target before
actually running the build itself. It doesn't matter how fast your
systems are, checking out 10,000 files is simply going to take time,
and when you do continuous integration, every minute counts.

We have a rule:

* All items should be built in "target" with items you want Jenkins to
keep in target/archive. That way, a "clean" only has to delete the
"target" directory. If this isn't practical, then you should make sure
that any stray items are hit by the clean target.

* You should never munge files that are under version control. Never,
never, never. That means we don't use the <replace> task in Ant.
Instead, we <copy> with <filterset>.

In theory, you should have your build structured that you don't even
need to run "clean". If something is already built, why rebuild it?

I worked at one company where the standard build took 4 hours. I
restructured it, and used CruiseControl (Hudson wasn't around yet) not
to do a clean before the build. The entire build took less than 15
minutes that way. At the end of the day, I would do a clean and build
which did take about 4 hours, but that was mainly for show. The
unclean building allowed us to do continuous integration. You can't do
continuous integration if you don't know your build results for four
hours.

--
David Weintraub
qaz...@gmail.com