> Does that mean you just have drawn the dialogs, or that you already
> implemented the features?
Yes, the features shown in the screenshots are implemented. They are in 6 files.
> 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.
Yes that is possible. But in teams that do bug-fixing most of the
time, people like to group files relevant to each bug. In such cases
it is very rare that one bug interferes with another.
The general idea is similar to the way Perforce changelists operate.
File can be grouped logically depending on need.
>
> 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.
I guess i've used confusing terminology. "Commit Groups" or something
like that would be much better.
> 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.
Possible, but i've seen such files many times :)
> Again: did they just see the screenshots or could they actually *use* it?
Yes, i'd setup a installer on a test machine and then asked people for opinions.
Could you suggest how do i go about sharing my code?
> Why do you think that 'status' would be faster?
People would want to get the status of only the files in the "Commit
Group". So svn needn't crawl through the whole 1gig working copy.
> * how would you handle situations where a changeset includes the same
> file(s) as another changeset?
I suppose 1 file can be in multiple groups. This can be dicsussed for
its merits.
> * how would you handle new files? Where are they added, in which changeset?
The user can designate a group as a default group. He can add files to
the default group from explorer right-click menu. (I dunno if this is
acceptable, there are already too many entries in the menu).
If the user adds an unversioned file, it can be automatically
scheduled to be added in svn.
> * 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?
That is a problem we can do nothing about. The user will have to
refresh the group or all groups. We can even refresh when the dialog
is resumed.
> * 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?
Unless the user has added that file explicitly to the group, it
wouldn't be visible in the group.
Again, this can be discussed.
regards,
aniruddha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Oct 16 11:34:02 2005