Thank to both of you!
Steve Greenland wrote:
> On Wed, May 04, 2005 at 03:09:42PM +0200, Dirk Schenkewitz wrote:
>
>>Well. Normally I make comments like "improved handling of the
>>Z-data, speeds up things a lot" and not "Changed handling of
>>Z-data to speed things up, introduces a bug that will format all
>>your filesystems if you delete a file between midnight and 0:30" -
>
>
> But you should! As Andrew Morton wrote recently on the Linux Kernel
> Development list:
>
> It's nice that patches are called "fix the frobnozzle gadget", but
> this analysis would be a lot easier if people would also label their
> patches "break the frobnozzle gadget" when that's what they do.
:-) Andrew and you are absolutely right! I should think hard about
changing my habits regarding to this.
>>Just HOW can you fall back to a known good state? As long as you
>>don't know the cause of a certain problem? (After you found out, you
>>don't need any version management at all - fix the problem and it's
>>gone. :-)) Seriously - is/are there any method(s) that make it easier
>>to find an *unknown* bug or rather find the *cause* for a certain
>>problem, using some advantage of svn?
>
>
> Develop a test case that shows the bug. Find an older version that
> doesn't trigger the test failure. Now:
>
> A. If you've got some idea of where the bug is, look at the modified
> files for each changeset between "works" and HEAD. For those that touch
> files under suspicion, look at the diffs. For suspicious changes, run
> the test.
>
> OR
>
> B. If you're at a complete loss, it's binary search time. Pick a
> revision between "works" and HEAD, call it T. Test it. If it passes,
> then pick another between "T" and HEAD; if it fails, pick between
> "works" and "T". Repeat.
>
> (Not, I admit, a particular Subversion capability, just a nice property
> of doing VC at all.)
That's what I did with my comment-less system with the editor backups.
I would say that the commit messages are very helpful, if a change does
what the developer wants. But if there is an unexpected side effect, they
of very little help, IMHO.
Then again, I was the only developer at that time. SVN is aimed at a group
of developers, so it may perform better in that situation.
Another thought - are there methods to automatically do a checkin when
saving an edited file, maybe via scripts for editors? I just found one
for 'vim' (http://www.vim.org/scripts/script.php?script_id=922, I haven't
tried it out yet), does anyone know another? For example, I couldn't find
anything for 'Kate' (the favourite editor of a colleague) so far.
Thank you very much!
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 6 11:38:39 2005