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

SVN+latest NAnt in automated environment like CCNet

From: Martin Aliger <martin_aliger_at_gordic.cz>
Date: 2004-11-08 11:43:41 CET

Hi SVN team,

I'm user and occasional developer of CCNet, automated build tool. We are in
doubt whether and how SVN support clean updates which is very needed feature
for automated builds.

We need to update WC to specified revision, reverting all changes done in
previous build process and delete all artifacts which remains in WC (or do
not complain about them). There are 2 problems we identified with SVN up to
now:

1/ new artifacts files/subfolders in the WC
  - it is fine when normal added/modified files are updated, but SVN
complains about non-version file/folder when delete is performed on parent
folder

<exec program="c:\program files\subversion\bin\svn.exe" commandline="update
--non-interactive ${build.dir}"/>
External Program Failed: c:\program files\subversion\bin\svn.exe (return
code was 1)
svn: Won't delete locally modified directory c:/ccnet/foo'
svn: Left locally modified or unversioned files

2/ modified files exists in repository (and update is needed)

automated builds need always clean copy. So we have to perform revert+update
in order to get clean copy. Is there any "--clean" switch to update?
(alternative of "CVS -q update -d -P -C")

Powered by Subversion 1.0.5 (r9954)

Martin

[snip of interesting parts of our discussion attached]
  
> > To me this is a bug in subversion. One of the most obvious
> use-cases
> > aren't supported; automated builds.
> > I'd love to see many of Subversions commands have a --force
> parameter
> > so that I didn't have to work around it.
> >
> > I do howevery think that if a task is supposed to do what VS does,
> > then it should do so. Otherwise one would have to invent different
> > hacks for different compilers.
> > Remember that users of VS automatically ends up with these
> bin and obj
> > folders and have to deal with them as well.
> >
> > /Nicke

> It sounds like NAnt is now doing what VS does so that sounds
> like the right thing to me.
>
> Files that are *created* (and not editted) by a build process
> should be marked as 'ignore', and I believe that should fix
> the problem (certainly that works when using CVS).
> Furthermore, we're used to automated builds having a 'clean'
> task - if necessary they could have a 'teardown' task to
> remove any temporary artifacts, but I think a combination of
> ignored files/directories and just a 'clean' build task is fine.
>
> Mike

> > Hi all,
> >
> > just FYI latest NAnt change behaviour of build process
> little and now
> > <solution> task produce obj folder under project directory.
> This match
> > VS.NET behaviour what is good. What is bad it could broke
> automated builds!
> >
> > I notice that when some user want to delete entire project
> under SVN.
> > Since local repository is modified by NAnt build process
> (new subdir),
> > svn is unable to delete project and fail with message
> >
> > <exec program="c:\program files\subversion\bin\svn.exe"
> > commandline="update --non-interactive ${build.dir}"/>
> External Program
> > Failed: c:\program files\subversion\bin\svn.exe (return code was 1)
> > svn: Won't delete locally modified directory c:/ccnet/foo'
> > svn: Left locally modified or unversioned files
> >
> > Even Revert+Update do not help (revert do not touch
> unversioned files).
> > Deleting all obj folders (what is only solution I see)
> could be quite
> > performance hit for very large projects. And, of course, more work,
> > more complex .build script etc. I'd say I liked old
> behaviour more...
> >
> > Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 8 17:22:34 2004

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.