RE: [Subclipse-users] Subclipse and the out of date folders feature, more to say?

-----Original Message-----
From: Mark Phippard [mailto:markphip@gmail.com]
> Sent: Sun 12/24/2006 3:03 PM
> To: users@subclipse.tigris.org
> Subject: Re: [Subclipse-users] Subclipse and the out of date folders feature, more to say?
>
> On 12/24/06, MATHUS Baptiste <mathus.b@mipih.fr> wrote:
> > Wouldn't it be interesting to add some related feature to this: add an
> > option to automatically run update after a commit? I would personnally
> > really be interested into having such feature. Moreover, I can't see a use
> > case where someone would be interested in not running update after any
> > commit to be up to date. Is there any thing I'm missing about it? If there
> > is no interest in not running this update, why not rename/change the actual
> > option to "automatically run update after commit"?
> >
> > If you agree with the interest of such a feature, but have no time in
> > implenting this, I could try and cope with subclipse code to add this. But
> > as you already said, Mark, it's better agreeing on a subject with the
> > subclipse developers when working on patch, so as not to work for nothing
> > :).
> >
> I would be interested to hear what others think. Personally, I am very much
> against it. It violates the push/pull philosophy of Subversion as expressed
> here in the Subversion book (look for the heading "Updates and Commits are
> Separate"):

Yes, I quite agree with you. But in fact, as you said, the thing is that with graphical interface, you're more often updating only some files, directories, and committing the same way. So, I precise this option is obviously one that's reserved to subclipse.

Most of the time, here's what I do with versions control system, and that's how we ask our developers to proceed (at the moment, they're still using cvs as we already use/test svn eclipse integration using subclipse, in our "dev support" team) :
1 - Team/Synchronize
2 - update what must be updated
3 - commit

With subclipse, there's a fourth one
1 - Team/Synchronize
2 - update what must be updated
3 - commit
4 - update

So, 99 times on 100, this fourth step is only aimed at updating nothing else than parent dirs of updated files...

>
> http://svnbook.red-bean.com/en/1.2/svn.basic.in-action.html#svn.basic.in-action.mixedrevs.update-commit
>
> I think there are plenty of negatives that can come from it, namely that
> other changes have been committed since you initiated the Synchronize, and
> now you receive unexpected updates in your working copy. The other issue is
> that you would not have an obvious "target" for the update command.
> Meaning, I do not think you could just update the project root, and if not
> that, then what would you choose to update? Updating the files that were
> committed would not be of any value, and if you do not update to the project
> root, then you haven't accomplished what seems to be the goal in doing this
> in the first place.

Well, I totally agree with the fact that the associated risk would be to retrieve changes you don't want. Isn't there any way of asking svn to update only directories versions, not files in it?

Maybe the alternative when activating this option could be to show a confirmation dialog saying something like "Some files have been committed. The parent directories have to be updated, do you want to run update now?". This dialog would show right after committing, even if committing directly from, say, the Java perspective using Team/commit or a shortcut.

-- Baptiste

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org