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

Re: SV: Re: Re: Re: Extending TortoiseSVN/Subversion

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2006-08-06 18:24:50 CEST

Jared Hardy wrote:

> In the Commit dialog now, once the list of modified files is
> populated, you can select one or more paths from the list, and have
> the right-click options of "Revert...", "Delete", and "Get Lock". I
> would also like the option of "Update", to help prevent the situations
> where a Commit fails simply because a file is not up to date, but not
> conflicted with HEAD. Files that are conflicted after the Update could

Updating from the commit dialog? That's a very bad idea! Because an
update can change the status of files, which are already shown in the
commit dialog. And that would mean either *guess* the new status or do a
full status fetching again - and then you could just do the update
outside the commit dialog and hit F5 afterwards.

> be revised in the Commit dialog list after update, if necessary. In
> fact, I would like an option to "Lock and Update", where the default
> Lock message would be "Attempting Commit" or something similar, and

Are you saying you want to lock a file to *prepare* for a commit?
That's just the wrong way to work with Subversion. Seriously!

> thus not require a Lock dialog spawn. This feature assumes the "Keep
> locks" is unchecked, so maybe it would become "Lock and Update..."
> with a Lock dialog spawn, in cases where it *is* checked.

> This may already be the case now, but if a conflicted file appears
> in the Commit path list, it would be nice if right-click gave the
> options "Revert", "Resolve", and "Diff". That way conflicts could be
> resolved without leaving the Commit dialog, and the dialog may be able

Bad idea! You will understand the problem as soon as someone resolves
such a conflict, commits and breaks the build with it.
Resolving a conflict is not an easy task. And speaking for myself I
would forcefully explain to all users that after resolving a conflict, a
build is in order to check if the resolving really is ok. *Then* you can
commit again. But if you haven't resolved the conflict when you fire up
the commit dialog, that means you haven't built your project yet and you
shouldn't commit in the first place.

> to update the status once an Exit condition on the spawned sub-dialog
> is detected. Maybe this functionality already exists -- I'm not sure.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Aug 6 18:25:03 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

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