CODEWITHSUNDEEP
svnversion-controltortoisesvn
user1391279
user1391279

Reputation:

Version control practices - interal class specific versions

I have a reasonably small project that I would like to put under version control (Subversion + Tortoise). Currently, I am using internal (comment based) class documentation to keep track of the changes made to the individual classes. Thus, each class has its revisions log within the documentation, e.g.

%   Revision 1.0.0 (Author name, 19/08/2015)
%       Defined basic functionality.
%   Revision 1.0.1 (Author name, 19/10/2015)
%       Introduced abstract methods for the definition of the connection interface
%       in-situ.

I am interested in whether it is appropriate to keep the current system of tracking changes in the individual classes/files or I should abandon it and only specify the changes in the log messages before making a commit. My concerns regarding using the version control log system only is that it is unlikely to be as detailed as the internal system (i.e. typically a commit needs to be associated with multiple classes/files). On the other hand, it does feel very awkward to have two different revision numbers associated with one file.

Upvotes: 1

Views: 33

Answers (1)

Anton Gogolev
Anton Gogolev

Reputation: 115809

These comments just scream "put me in commit messages". Dates, author - these are all captured explicitly when committing. Plus, how do you plan to deal with situations where a change affects multiple classes?

(There's a lot of guides on how to write good ones (1, 2, 3) regardles of what VCS is being used.)

As for class version numbers - there's really no point in doing so. What is this useful for? It's not like you can pick an choose which minor version of the class you'll be using. What should be versioned is the entire library/application, and versioned according to (preferably) SemVer.

Upvotes: 1

Related Questions