Hal Vaughan wrote:
> I've found "Version Control with Subversion" very helpful, but I
> haven't been able to go through the entire book at this point
> (probably won't have time for a good while to read it all). I've had
> two problems to solve, and this group was most helpful with the first
> one a while ago (ignoring directories).
> The only other issue I have is that typos are VERY easy for me, it's
> part of a learning disability. When I first finish writing a new
> program or library, I want to commit it right away, for safety.
> However when I test run it, I'll find typos that syntax highlighting
> didn't show. I'd like to be able to fix small errors like this
> without creating a new version when I commit. I think this would
> essentially be editing a committed version (usually the head) without
> creating a new version. I don't want to do this for big errors or
> bugs, but it would be a huge help to not have different versions with
> the only difference between them being the fixing of a few typos.
> Is there a way to edit an already committed version (again, usually
> the head) without creating a new version?
Sounds like you've got the wrong idea of a "version". The meaning of
"version" as far as subversion (and CVS, and all other version control
systems) is "any time a file has changed", while you seem to be thinking
of it as "program version". A program's files will go through many
versions between releases; thus, there will not be a one-to-one mapping
from the one sort of "version" to the other.
The standard attempt at clarifying this is to call the "program
versions" tags or releases, instead of versions.
So, that said: the answer to your question is no--whenever you commit
changes a file, it will be given a new version number (since it is now
different from the previous file). This makes sense, since otherwise
you wouldn't be able to tell when/how changes had been made. But you
can, however, create a 1.0 tag, add files to it, change files, etc., and
keep it at tag 1.0 (though that's generally frowned upon as well, for a
variety of reasons).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Oct 18 17:26:43 2005