Dirk Schenkewitz wrote:
> Hi John and all,
>
> I'm playing the evil one, hoping that the answers will give me/us some
> arguments for using svn (instead of nothing).
>
> John Szakmeister wrote:
>
>> ...
>>
>> But the problem is that you only know what *you* are putting into the
>> repository. If you blindly commit everyone else's code at the end of
>> the day, neither you nor your teammates knows what it is. It makes it
>> much more difficult to fall back to a known good state
>
>
>> (Did the code in the directory work? Were they in the middle of
>> something?
>
>
> Ok, they would not check in if the are in the middle of something, but
> what if they *believe* that the code works?
That's a different problem entirely. It doesn't help you make a point
of using version control if you can't fall back to something that you
know is good, or can't properly track where a potential change was
introduced. Part of this is having adequate log messages to go back and
review what was changed. Many times I've been able to walk back through
log messages alone and find the revision that introduced the problem.
not only that, the log message helps to serve as a reason of why I
changed (perhaps I fixed one bug and accidentaly introduced another).
>> What changes did they make?).
>
>
> 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" -
> I mean, the comments are not so that you can find a bug from looking
> at them, esp. if (as long) you don't know what the cause is.
No, but you can track what was modified, and what problem a particular
commit was trying to solve. Not having that information makes things
more difficult.
>> Some amount of diff'ing will help, but that only ruins the perception
>> of version control, because it didn't make it easy to fall back to a
>> known good state.
>
>
> 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?
No, there's no magic here. But being diligent with log messages and
changesets can make it easier to track when a bug was introduced and
perhaps how it was introduced and for what reason (not the you purposely
introduced a bug, but you may find out that it was a side effect of
another fix).
>> And what about added files, removed files, and renamed files? The
>> svn_load_dirs.pl script can help with this to a degree, but you lose a
>> lot of valuable information without the user typing in commit messages
>> about what they've done. IMHO, it can make the difference between a
>> good and bad version control experience.
>
>
> You're right with the loss of information. But, speaking for myself as
> "the user": What the user thinks he has done is sometimes not the
> important part of what he really has done.
Sure, we make mistakes. But developing good SCM habits will get you
thinking in the right direction. And when it doesn't work, you can fall
back to other tools (diff, blame, etc) to help figure what really happened.
> What should a commit message contain?
> - what I wanted to do.
> - how I did it.
> What else?
> As said above, since most of the developers create bugs accidentally,
> they don't mention them in the commit message. Therefore, how does a
> version management like svn speed up finding the "last good version",
> compared to, say, a simple code freeze. I believe, if you want to find
> the "last good version", a code freeze system is faster, because you
> have less work to do. Not to speak of the time you need to actually
> perform the commit everytime.
I'd take a look at the commit messages that the Subversion uses. I'm
not all that excited about the format, but it does contain key bits of
information:
1) An overall description of the change (what problem the commit is
trying to solve).
2) What files were affected, and more importantly
3) Which functions or symbols did you change in the commit
I find those 3 key pieces of information invaluable during my daily
work. I watch the messages as they come in, so I'm always aware of
where other developer's are spending their time. I also scrutinize
their commits, and they scrutinize mine. It ensures we have a clean
code base, and that we aren't kludging a solution.
I don't think a code freeze offers any speed advantage. In this case,
you can use 'svn up' to move your working copy to a previous version.
Situations depend on your development environment. In our, critical
bugs are stumbled on pretty quickly (well, most of them). 9 times out
of 10, dropping back to the previous version of a file results in
successful completion of the tests. At that point, I've narrowed down
the problem code to a particular revision. If that's not the case, I
fall back to the log messages, and attempt to work from a revision that
I knew worked correctly (believe it or not, you remember these things
pretty well). It's never taken me longer than 10 minutes to find the
problem revision. And to be honest, that number is probably more like 3
minutes.
> Some years ago I "developed" a "versioning system" out of chance, per
> accident, so to say. Well, it actually had nothing to do with real
> versioning:
> I fixed up my favourite editor, joe, to create numbered backups, like
> emacs can do. These were just left as they were, complete chaos, only
> that I moved them to a hidden directory from time to time. Later, when
> I realized that this ate up huge amounts of disk space, I wrote a script
> that used rcs to store these "versions" much more space-efficiently.
>
> The big advantage was, during development I didn't need to think about
> it, I even could not forget to commit something, the editor was silently
> doing all the work for me. The disadvantage was that there were no
> descriptions of the changes.
>
> Once I created a bug. Nobody noticed for a long time. Then, about one
> year an hundreds of small changes later, someone ran into it.
> I checked out the older binaries of the program to find the latest
> good version, it lead me one year back. Since I had a vague idea in
> which directory the bug might have happened, I simply fetched all the
> numbered backups from the rcs into that directory and started to compare
> and try out, one by one. All in all it took about one hour to find the
> bug and to fix it.
Again, it all depends on your development pattern, but I've found that
the log messages and being diligent about changesets has been extremely
beneficial to us. All in all it saves us hours every week, and that's
more time that we spend working on the problems instead of trying to
find their locations through other means.
Can you get by without stuff, sure. Should you? It depends. But when
you're trying to show a group individuals the benefits of using version
control, you're cutting out half the benefit by cutting out the
changeset idea and providing adequate log messages. Version control
offers much more than a fancy numbering scheme. It can help you track
changes along different lines of developments, record significant
milestones, provide a great overview of the changes that have been made,
and when tied with things like hook-scripts, can provide communication
between developers about what they're doing. Actually versioning the
data is really only half the battle, IMHO.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 4 15:59:43 2005