attention all subversion users

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

attention all subversion users

kaxelson
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

Dean Yu
Re: attention all subversion users 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" <kaxelson@...> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...


Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

Tom Huybrechts
I agree. With a little extra effort you can have this feature/bugfix
while maintaining current behaviour for those that are depending on
it.

On Sat, Jul 4, 2009 at 8:25 PM, Dean Yu<[hidden email]> wrote:

> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

Kohsuke Kawaguchi
Administrator
In reply to this post by Dean Yu
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 <[hidden email]>:

> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>



--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

Wim Rosseel
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 <[hidden email]> 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 <[hidden email]>:
> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>



--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

kaxelson
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 <[hidden email]> 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 <[hidden email]>:
> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>



--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

Timothy Bingaman
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>:
> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>



--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





--
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
Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

Wim Rosseel
I second Timo's suggestion
Just make it so that the people seeking a change in behaviour need to reconfigure.
This normally results in less people being impacted :-).
Which is of course good for the backwards compatibility.

Anyhow i personally think that incompatible changes should be put in a new major release. But changing the major version number is koshuke's call I guess.
Considering the amount of people currently already using hudson I would consider it favorable to adopt  a major.minor.hotfix numbering scheme. After all the more people are using hudson the bigger the impact if a, so called, minor release causes breakages in the behaviour .

greets,

Wim


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


On Mon, Jul 6, 2009 at 1:25 AM, Timothy Bingaman <[hidden email]> wrote:
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 <[hidden email]>

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 <[hidden email]> 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 <[hidden email]>:
> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>



--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





--
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

Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

Jesse Glick
In reply to this post by Kohsuke Kawaguchi
Kohsuke Kawaguchi wrote:
> 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.

For example, clean unversioned files, like the Mercurial plugin already does:

https://hudson.dev.java.net/nonav/issues/show_bug.cgi?id=3390


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: attention all subversion users

Dean Yu
In reply to this post by Timothy Bingaman
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:[hidden email]]
> Sent: Sunday, July 05, 2009 4:25 PM
> To: [hidden email]
> 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 <[hidden email]>
>
>
> 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 <[hidden email]> 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 <[hidden email]>:
>
> > 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"
> <[hidden email]> 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:
> [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
> >
> >
>
>
>
>
> --
> Kohsuke Kawaguchi
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>
>
>
>
>
>
> --
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

kaxelson
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 [[hidden email]] 
Sent: Sunday, July 05, 2009 4:25 PM
To: [hidden email]
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 [hidden email]


	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 [hidden email] 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 [hidden email]:
			
			> 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" 
[hidden email] 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: 
[hidden email]
			> For additional commands, e-mail: 
[hidden email]
			>
			>
			>
			
			
			
			
			--
			Kohsuke Kawaguchi
			

			
---------------------------------------------------------------------
			To unsubscribe, e-mail: 
[hidden email]
			For additional commands, e-mail: 
[hidden email]
			
			





--
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


    

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  
Reply | Threaded
Open this post in threaded view
|

RE: attention all subversion users

Dean Yu
You can't assume that people are going to upgrade through every single
release. What happens to people that are on 1.313 and don't upgrade
until 1.315? They'll miss the migration logic.

  -- Dean

> -----Original Message-----
> From: Knute G. Axelson [mailto:[hidden email]]
> Sent: Monday, July 06, 2009 11:45 AM
> To: [hidden email]
> 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:[hidden email]]
> Sent: Sunday, July 05, 2009 4:25 PM
> To: [hidden email]
> 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 <[hidden email]>
> <mailto:[hidden email]>
>
>
> 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 <[hidden email]>
> <mailto:[hidden email]>  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
> <[hidden email]> <mailto:[hidden email]> :
>
> > 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"
> <[hidden email]> <mailto:[hidden email]>  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:
> [hidden email]
> > For additional
> commands, e-mail:
> [hidden email]
> >
> >
> >
>
>
>
>
> --
> Kohsuke Kawaguchi
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional
> commands, e-mail:
> [hidden email]
>
>
>
>
>
>
>
> --
> 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
>
>
>    
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

kaxelson
You make a good point.  I think I can work out some migration logic that won't required staggered releases.

-Knute

On 7/6/2009 2:04 PM, Dean Yu wrote:
You can't assume that people are going to upgrade through every single
release. What happens to people that are on 1.313 and don't upgrade
until 1.315? They'll miss the migration logic.

  -- Dean 

  
-----Original Message-----
From: Knute G. Axelson [[hidden email]] 
Sent: Monday, July 06, 2009 11:45 AM
To: [hidden email]
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 
[[hidden email]] 
		Sent: Sunday, July 05, 2009 4:25 PM
		To: [hidden email]
		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 [hidden email] 
[hidden email] 
		
		
			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 [hidden email] 
[hidden email]  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 
[hidden email] [hidden email] :
					
					> 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" 
		[hidden email] [hidden email]  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: 
		[hidden email]
					> For additional 
commands, e-mail: 
		[hidden email]
					>
					>
					>
					
					
					
					
					--
					Kohsuke Kawaguchi
					
		
					
		
---------------------------------------------------------------------
					To unsubscribe, e-mail: 
		[hidden email]
					For additional 
commands, e-mail: 
		[hidden email]
					
					
		
		
		
		
		
		--
		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
		
		
		    

	
	
---------------------------------------------------------------------
	To unsubscribe, e-mail: [hidden email]
	For additional commands, e-mail: [hidden email]
	
	  


    

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  
Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

Kohsuke Kawaguchi
Administrator
Knute G. Axelson wrote:
> You make a good point.  I think I can work out some migration logic that
> won't required staggered releases.

Here's what I propose:

1. Define an extension point in core to abstract away various "clean"
logic. Say "WorkspaceCleaner" (a better name suggestion that doesn't
sound similar to the current WorkspaceCleanupThread is welcome!)

This works like RepositoryBrowser, in the sense that:

 - some implementation may work across SCM, while others may
   be tied to a particular SCM implementation.
 - it's held by SCM and called by SCM.

2. Evolve SubversionSCM code so that the current boolean switch of
"clean vs update" will map to two different implementations of
WorkspaceCleaner.

3. Your clever Subversion clean up logic can be implemented as
WorkspaceCleaner implementation.



As Jesse noted, this enables other interesting clean up strategies, like
just removing unversioned files, or rolling back to earlier ZFS
snapshot, etc.

I can help with the implementation. In the mean time, I'll roll back
3580 and 3966 so that the next 1.315 release can proceed.

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

zzyzx-2
I should probably chime in here since I am one of the users who was encouraging
kaxelson to change the current behavior.  As was mentioned above, the problem is
with shared workspaces.  We have a common set of subsystems that are shared by
several apps.  The subsystems need to be built first, followed by each of the apps.
The source code assumes all the different projects are rooted in the same folder.

So in Hudson, we defined a custom workspace folder at
/workspace

the subsystems get checked out from svn into
/workspace/subsystems

app1 gets checked out to
/workspace/app1

and so on.  The subsystems project gets built by polling SVN, and the apps are
triggered as dependent projects.

Now the problem with Hudson's current behavior is that when it goes to run the
subsystems project, it deletes the entire workspace.  That means the subsystems
AND the app folders all get deleted.  Hudson then proceeds to check out all of
the subsystems source, and then executes the build script.  This is fine so far.

App1 is then triggered.  Hudson proceeds to delete the entire workspace again,
including the subsystems folder that was just built!  It then executes the build
script, which fails because the required subsystem files are no longer there.

Of course, if you trigger the subsystems again, the entire process repeats itself.
Each project deletes all the files needed by the other projects when the workspace
is cleaned.

That said, I think many wise people here have raised a good point about backward
compatibility.  Since users like me are the ones asking for the change, it is
reasonable to expect US to toggle a checkbox or whatever.  I agree that existing
users should not be required to change anything to maintain their current behavior.

Heck, all I want is a way to make my builds work and I will be happy! :)

--Dan

kohsuke wrote
Knute G. Axelson wrote:
> You make a good point.  I think I can work out some migration logic that
> won't required staggered releases.

Here's what I propose:

1. Define an extension point in core to abstract away various "clean"
logic. Say "WorkspaceCleaner" (a better name suggestion that doesn't
sound similar to the current WorkspaceCleanupThread is welcome!)

This works like RepositoryBrowser, in the sense that:

 - some implementation may work across SCM, while others may
   be tied to a particular SCM implementation.
 - it's held by SCM and called by SCM.

2. Evolve SubversionSCM code so that the current boolean switch of
"clean vs update" will map to two different implementations of
WorkspaceCleaner.

3. Your clever Subversion clean up logic can be implemented as
WorkspaceCleaner implementation.



As Jesse noted, this enables other interesting clean up strategies, like
just removing unversioned files, or rolling back to earlier ZFS
snapshot, etc.

I can help with the implementation. In the mean time, I'll roll back
3580 and 3966 so that the next 1.315 release can proceed.

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

 
Reply | Threaded
Open this post in threaded view
|

RE: attention all subversion users

Nord, James
In reply to this post by Kohsuke Kawaguchi
> Knute G. Axelson wrote:
> > You make a good point.  I think I can work out some migration logic
> > that won't required staggered releases.
>
> Here's what I propose:
>
> 1. Define an extension point in core to abstract away various "clean"
> logic. Say "WorkspaceCleaner" (a better name suggestion that
> doesn't sound similar to the current WorkspaceCleanupThread
> is welcome!)
>
> This works like RepositoryBrowser, in the sense that:
>
>  - some implementation may work across SCM, while others may
>    be tied to a particular SCM implementation.
>  - it's held by SCM and called by SCM.

Hmmm..  This would be usefull for the Maven local repository as well.

For instance on a release build I could delete the local repository - or
just the modules that are contributed from the build.
(which I can do anyway inside the m2release plug-in - but if there is a
single extension point...)

> 2. Evolve SubversionSCM code so that the current boolean
> switch of "clean vs update" will map to two different
> implementations of WorkspaceCleaner.
>
> 3. Your clever Subversion clean up logic can be implemented
> as WorkspaceCleaner implementation.
>
>
>
> As Jesse noted, this enables other interesting clean up
> strategies, like just removing unversioned files, or rolling
> back to earlier ZFS snapshot, etc.
>
> I can help with the implementation. In the mean time, I'll
> roll back 3580 and 3966 so that the next 1.315 release can proceed.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                  
> http://weblogs.java.net/blog/kohsuke/
>

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [hidden email] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: attention all subversion users

Kohsuke Kawaguchi
Administrator
In reply to this post by zzyzx-2

Thanks for your thoughts. I don't think anyone is arguing against the
feature itself, so that's good. I believe my proposal on the table would
eventually get you what you need.

zzyzx wrote:

> I should probably chime in here since I am one of the users who was
> encouraging
> kaxelson to change the current behavior.  As was mentioned above, the
> problem is
> with shared workspaces.  We have a common set of subsystems that are shared
> by
> several apps.  The subsystems need to be built first, followed by each of
> the apps.
> The source code assumes all the different projects are rooted in the same
> folder.
>
> So in Hudson, we defined a custom workspace folder at
> /workspace
>
> the subsystems get checked out from svn into
> /workspace/subsystems
>
> app1 gets checked out to
> /workspace/app1
>
> and so on.  The subsystems project gets built by polling SVN, and the apps
> are
> triggered as dependent projects.
>
> Now the problem with Hudson's current behavior is that when it goes to run
> the
> subsystems project, it deletes the entire workspace.  That means the
> subsystems
> AND the app folders all get deleted.  Hudson then proceeds to check out all
> of
> the subsystems source, and then executes the build script.  This is fine so
> far.
>
> App1 is then triggered.  Hudson proceeds to delete the entire workspace
> again,
> including the subsystems folder that was just built!  It then executes the
> build
> script, which fails because the required subsystem files are no longer
> there.
>
> Of course, if you trigger the subsystems again, the entire process repeats
> itself.
> Each project deletes all the files needed by the other projects when the
> workspace
> is cleaned.
>
> That said, I think many wise people here have raised a good point about
> backward
> compatibility.  Since users like me are the ones asking for the change, it
> is
> reasonable to expect US to toggle a checkbox or whatever.  I agree that
> existing
> users should not be required to change anything to maintain their current
> behavior.
>
> Heck, all I want is a way to make my builds work and I will be happy! :)
>
> --Dan
>
>
> kohsuke wrote:
>>
>> Knute G. Axelson wrote:
>>> You make a good point.  I think I can work out some migration logic that
>>> won't required staggered releases.
>>
>> Here's what I propose:
>>
>> 1. Define an extension point in core to abstract away various "clean"
>> logic. Say "WorkspaceCleaner" (a better name suggestion that doesn't
>> sound similar to the current WorkspaceCleanupThread is welcome!)
>>
>> This works like RepositoryBrowser, in the sense that:
>>
>>  - some implementation may work across SCM, while others may
>>    be tied to a particular SCM implementation.
>>  - it's held by SCM and called by SCM.
>>
>> 2. Evolve SubversionSCM code so that the current boolean switch of
>> "clean vs update" will map to two different implementations of
>> WorkspaceCleaner.
>>
>> 3. Your clever Subversion clean up logic can be implemented as
>> WorkspaceCleaner implementation.
>>
>>
>>
>> As Jesse noted, this enables other interesting clean up strategies, like
>> just removing unversioned files, or rolling back to earlier ZFS
>> snapshot, etc.
>>
>> I can help with the implementation. In the mean time, I'll roll back
>> 3580 and 3966 so that the next 1.315 release can proceed.
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/
>>
>>  
>>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

smime.p7s (4K) Download Attachment