[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN equivalent for CVS history

From: BRM <bm_witness_at_yahoo.com>
Date: 2007-05-09 18:23:53 CEST

--- Nathan Kidd <nathan-svn@spicycrypto.ca> wrote:
> Méresse Christophe wrote:
> > nikhil gupta wrote:
> > > Thanks for the reply.
> > > My actual target is to compile only those solutions which
> were
> > > updated the previous day. For this I need to have the list of
> those
> > > files first. Apart from this, my organization has
> development, both
> > > at US and India. So, its like the development is on round the
> clock
> > > & we can not cut things off.
> But Nikhil, I think you're approaching this problem from the wrong
> angle.
> If you have a requirement to build only solutions that have changed,
> then it should be the job of your build system to have proper
> dependencies and only build what has changed, based on what is on
> your disk (not parsing update logs).
> SVN revisions become meaningless in your project if you have to say
> "This build was made from whatever projects we felt like updating and
> building at such-and-such a time". A more robust approach is to 'svn
> up' for every build (no room for missing anything, your tree is in a
> consistent state at a definite revision number), then teach your
> build system to build targets only when sources have changed.

Perhaps another solution is to go with a branch methodology for this.

Instead of just going off the head of all your projects to do this...

1) Have work on some trunk/branch
2) Create a specific branch that will be checked out by your system
3) Have routine merges done between #1 and #2 to keep #2 up to date
with where you want to be looking at. (cron job? scheduled task?)
4) Have you system 'svn update' its check outs of #2 and perform its
tasks.

This should keep you from having to go through a huge list of things as
you should only be having to look at each project specifically.

It's possible you could just do this with #1 as #2 is essentially a
copy of it; but this could give you some leeway with ignoring some work
if you wanted (e.g. skipping a couple changes), or cutting down on what
is required for it to look at. You'd essentially be dedicating a branch
for your system.

Any how...just a thought...

BRM

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 9 18:24:13 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.