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?
> 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.
> 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?
> 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.
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.
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.
Dirk
---------------------------------------------------------------------
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:15:02 2005