-----Original Message----- From: Knute G. Axelson [mailto:kaxe...@gmail.com] Sent: Monday, July 06, 2009 11:45 AM To: de...@hudson.dev.java.net Subject: Re: attention all subversion users

OK, I think I have a solution that will work for everyone. We can release 3966 along with migration logic first. Then, next version we can release 3580 with migration logic removed. This will allow existing projects to be auto-migrated in the interim without introducing confusion over why someone left "use update" unchecked. How does this sound to you all?

-Knute

On 7/6/2009 1:17 PM, Dean Yu wrote:

Sorry, but I don't think that staggering the release of the features is an acceptable minimal solution. This change forces people to have modify working configurations to keep them working. There are many options to keep existing builds working without forcing them to change. To name a few off the top of my head:

1) Add a new configuration option to enable the new behavior, leaving it off by default 2) Add a version field to projects to detect pre-existing projects and revert to old behavior 3) Figure out how to map the old behavior to the new options and auto-migrate old projects

Again, requiring people to reconfigure working projects to just maintain expected behavior is not a good experience, and something I believe can be avoided with a bit more work.

-- Dean

-----Original Message----- From: Timothy Bingaman [mailto:timo...@gmail.com] Sent: Sunday, July 05, 2009 4:25 PM To: de...@hudson.dev.java.net Subject: Re: attention all subversion users

Unless a more seamless solution if found, I think at the very least Knute's proposal of staggering the changes would be good. We have over 50 builds running on our Hudson server (I'm sure other people may have a lot more) and quite a number of them rely on the current behaviour to clean up artifacts and other files left in the workspace root. It'd be a lot nicer if we had a week or two in between upgrades to reconfigure them.

Alternatively, I think it'd make more sense to have the box default to being checked if "use update" is false (If Hudson can determine that easily) and force people who use a shared workspace to uncheck it. They are the ones that are looking for the changed behavior and would be more aware of having to reconfigure their builds. People not using a shared workspace won't be aware of the reasons for this change and will be confused if their workspaces suddenly are not being cleaned up. This would at least maintain the current behaviour and allow the changes to be released together.

Timo

2009/7/6 Knute G. Axelson <kaxe...@gmail.com> <mailto:kaxe...@gmail.com>

Wim, you are correct about the motivation for this change. It fixes a problem for people using a shared workspace.

I appreciate the point that is being made about backward compatibility. The problem is that the new "clean workspace before build flag" is not equivalent to leaving use update unchecked post-3580. So, it doesn't work to link the two options. It would be nice to be able to automatically change the setting for people who are currently depending on the workspace being deleted, but how would we distinguish those people from others who will, leveraging the new logic, leave use update unchecked only because they want the checkout deleted and not the workspace. Maybe it's possible to have a one time process that runs when the new version is deployed that would migrate existing jobs.

Perhaps we could handle this by releasing the 3966 fix a few weeks ahead of the 3580 fix. This would give people more time to change their project configurations. What do you all think?

-Knute

On 7/4/2009 2:01 PM, Wim Rosseel wrote:

Hmm,

I tend to agree with the statements on trying not to change the old behaviour. After all if you have an advanced option to select the old behaviour, it really just comes down to flipping the logic for the advanced flag ;-) So default nothing changes (you might even have the advanced flag checked by default) and in the advanced section you can enable the new behaviour.

By the way koshuke I believe the feature request came from people working with shared workspaces. In their cases a full wipe of the workspace was unacceptable.

Does that make sense for everyone.

greets,

Wim

Nam-tor Ozhika kluterek t'sha'sutenivaya - k'ish she-tor etek s'nezhak - isan utvau vah sha'kakhartayek.

On Sat, Jul 4, 2009 at 8:43 PM, Kohsuke Kawaguchi <kk...@kohsuke.org> <mailto:kk...@kohsuke.org> wrote:

I agree.

I haven't really looked HUDSON-3580 and HUDSON-3996 yet, but I'm also curious what the motivation is for just removing checked-out locations. The projects around me really only have two notions --- incremental build, which is via svn update, or a clean build, which is rm -rf. The new addition seems to be somewhere between that is relatively less common.

If different people want different "clean" strategy, maybe it's better off to make this another extension point? That would allow the clean up behavior to grow from a binary switch to a select-one-from-many dropdown combo box.

I wonder if that's better than having two checkboxes in two different places.

2009/7/4 Dean Yu <dt...@yahoo-inc.com> <mailto:dt...@yahoo-inc.com> :

> As I said in response to Michael's email, I think changes that alter the > behavior of existing projects is not good practice. You would be forcing > people to have to manually reconfigure an unknown number of projects to > maintain the current behavior. I understand the usefulness of the changes, > but I think more work needs to be done so that compatibility is maintained. > Adding logic to transparently "migrate" the configurations of existing > projects would be one way to approach this. > > -- Dean > > > On 7/4/09 8:48 AM, "Knute G. Axelson" <kaxe...@gmail.com> <mailto:kaxe...@gmail.com> wrote: > > 3580 and 3966 have been committed to trunk. If you are a subversion > user depending of the entire workspace being cleaned as a side effect of > not selecting "use update", please be aware that this behavior will > change. 3580 introduces a fix that will cause only the checkout > location to be removed, and not the entire workspace, when you leave > "use update" unchecked. 3966 introduces an option under the advanced > project configuration settings that allows you to indicate that the > entire workspace should be deleted before each build. In order to > maintain behavior consistent with your current builds, all users who > need the entire workspace deleted should select this new option. > >

--------------------------------------------------------------------- > To unsubscribe, e-mail: dev-...@hudson.dev.java.net > For additional commands, e-mail: dev-...@hudson.dev.java.net > > >

-- Kohsuke Kawaguchi

-- Timothy Bingaman Software Engineer, Open Cloud Limited Level 4, 54-56 Cambridge Tce, Wellington, New Zealand http://www.opencloud.com t: +64 4 977 4782 m: +64 21 027 33614 linkedIn: http://www.linkedin.com/in/timobingaman