Hi,
>> 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.
JMvL> That would mean that they are only available for a single developer
JMvL> (since they do not reside in the repository). Is that what you want?
I think the main point is this (I have added some clarification on how
I see it in square brakets):
> The changeset will not have local history. It is only a collection
> of files [stored in the working copy or "near it"]. Users can
> add/remove [modified] files from the collection [source: their
> working copy in their own computer]. On a successful commit, those
> many files will constitute [one] svn revision [and users will lose
> that group of commited files].
+1. I've been using SVN for ~1.5 years, and this dialog would be
useful - if added to current behaviour, not by replacing it. I agree a
branch-should-be-open-for-each-bugfix, but in my world you need "it"
NOW, and in big projects, switching is slow. I often work on two or
three bugs at a time, and when commiting, I select three files then
commit them with a description, then I commit again (waiting for
status to be re-fetched - for several seconds!) and select other 3 and
commit, then again...
I recall there was a petition some time ago about re-opening commit
window after a failed commit, or even after successful ones. If you
could organize your files in groups (forget the word 'changeset', it
is confusing) and commit one group at a time having cs1.png opened all
the time, I would find it very useful.
Of course, drag-and-drop between explorer and that dialog would be
useful. Also, in the commit dialog, if you could check some files and
a right-click on 'Create a <whatever-word-here> with these files'
would popup the cs1.png with a new group with that files... a
right-click on 'Add these files to <whatever-word-here>...' would be
great too... And some more things...
It should be described a little more, but I like the idea. Commit
dialog should stay as it is, so you are not forced to group-files in
order to commit. But if you want to, this could be a good way to
achieve it.
JMvL> That would mean that they are only available for a single developer
JMvL> (since they do not reside in the repository). Is that what you want?
I do think so. Forget the word 'changeset' - it is used in other
environments for a complete different thing. This thing is only a way
to re-organize my changed files to commit them not-at-once.
JMvL> But there would be no history in the repository about what constituted
JMvL> a changeset (especially if the bugfix is committed in several stages).
JMvL> If the local storage is lost, the changeset history is lost as well.
Well... that is not a problem. We now live without grouping files: if
they are lost, in the commit dialog click on several, group them and
here you are!
From my point of view, in the moment you commit a group, the group is
lost (there are no modified files in that group). You don't have to
remember which files were in what group.
Also, it would be useful if you mark a group as no-commit. For
example, web.config. I know the "good way" is to commit
"web.config.template" but not "web.config", and have each developer to
copy-and-adjust that file after a checkout. But sometimes an
out-of-the-box web.config works for 99% of situations, so all
developers use the same file, and if using .templates, whenever you
change the template you have to warn all of them: 'hey, a new template
is available, reapply it in your local copy'.
Imagine that you need to change a line today to test something. You
need to fix 2 bugs some-what related to that change in the web.config
file. If you could tell TSVN (not svn) to "forget about changes on
web.config for now" while fixing them, it would be great. In the
moment you revert changes on that file, the 'non-commit' group is lost
(which is desirable, because if later you want to do 'permanent'
changes on the file, you don't want it to be in the non-commit group).
As you're fixing those 2 bugs, you find something more and you start
working and forget about commiting... (yes, I know you should not work
as this, but *I have to* and I think some other people will too). You
end by fixing 5 bugs and you want to make 5 different commits... Here
is an example of why these dialogs would be great.
A last note: I really would like this to be implemented. I would even
be happy to code this and send a patch. If I don't do it is just
because I don't know VC++. If only TSVN were written in .NET...
Sorry for my English... I hope it is clear enough.
Best regards,
Fernando Nájera
--
avast! Antivirus: Mensaje saliente limpio.
Comprobado: 15/10/2005 15:58:40 - Base de datos: 0541-3, 14/10/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Oct 15 15:59:10 2005