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

Re: Version control? You're soaking in it!

From: Dirk Schenkewitz <schenkewitz_at_docomolab-euro.com>
Date: 2005-05-06 11:32:31 CEST

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!

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

This is an archived mail posted to the Subversion Users mailing list.

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