Re: Working with Changesets in TortoiseSVN. New dialog.

Aniruddha Apte wrote:
> Hi Devs (Stefan),
>
> First of all, thanks to Stefan, Luebbe, Simon and others for a
> beautiful and a wonderfully functional Tortoise who is cute looking as
> well :).

Thanks :)

> I've created a new dialog for working with explicit changesets. This
> dialog is similar to the RepoBrowser. The changeset and its
> constituent path names, log message would be stored as a file in some
> predefined folder similar to where the TSVN cache file is stored.

Does that mean you just have drawn the dialogs, or that you already
implemented the features?

> Screenshots are attached.
>
> I can see 2 benefits of such explicit changesets:
>
> 1. Users can segregate files they are currently working on into
> change-sets for much better bug-fix management. The developer needn't
> sift through all modified files to commit fix for a particular bug -

That's a dangerous approach! If you're working on a new feature, and
then you have to fix a bug which has nothing to do with your feature,
how can you be *sure* that you really fixed the bug? I mean the change
you make to fix the bug could interfere with the changes you've made
already for your new feature.

I think it's a bad working practice (changesets). Because those
changesets aren't really separated from each other. Your compiled binary
will *always* have *all* changes included, from all changesets. So by
creating such changesets, you show the user a separation which doesn't
really exist.

> just commit that changeset. In many environments certain files are
> never committed but modified temporarily for development purposes -
> these can be put into a "Don't commit" changeset.

Yikes! There's always a way to *not* have such files under version
control at all. And even if it might look like more work to set
something like this up, it's always worth the effort.

> An initial feedback of the demo from users in our company was very positive.

Again: did they just see the screenshots or could they actually *use* it?

> 2. Status and commit for the changeset would be *very* fast.

Why do you think that 'status' would be faster?

> I'd like to hear your comments and suggestions, and brickbats :).

* how would you handle situations where a changeset includes the same
file(s) as another changeset?
* how would you handle new files? Where are they added, in which changeset?
* how would you handle situations where files are
moved/replaced/deleted/renamed outside the changeset dialog (e.g. with
explorer or another SVN client) and the changesets don't match anymore?
* how would you show a user if a new file is in the working copy but not
yet added to version control? Maybe that file is important?

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