On 1/10/07, Owen Thomas <firstname.lastname@example.org> wrote:
> Thanks Jared (and Mark) for your comments. They are very helpful in
> allowing me to argue the merits for and against an implementation of
> this change rationale system.
> > I think what Jeff, Eric, and Mark were getting at, is that you could
> > re-conceptualize the svn:log property data, and transform it into your
> > "Change Rationale" format.
> Hmmm... I'm learning about svn:log as I write this.
> > Think of svn:log as a text file that always gets added with each
> > revision.
> That isn't a good image in terms of what details I want to record in a
> change rationale document. My reason for this statement is that all
> changes consequent to a revision are recorded in one file. While svn:log
> is very good for recording a revision's summary information about a
> whole change (and I will probably be using it as such) I fear it might
> become bloated and unmanageable recording rationale to changes in
> individual files affected by the revision. This is especially true for
> revisions that affected many (50 or more, say) modules.
why would you commit that many separate changes in one group?
> It can even be changed later, after commit.
> Now that's a definite point against the use of svn:log for recording
> change rationale. Rationale is history. What has happened happened, and
> nothing can be done to un-happen what has happened.
only when properly set up - its not on by default
> You can format this text data any way you want, CSV, ODF, XML,
> > YAML, INF, CONF, etc. Or make up your own format.
> As said in an earlier post, if I can have this, I will.
> > Either way you implement this "Change Rationale" system, you're
> > going to need to wrap your "svn commit" actions with some custom
> > script to initiate the "rationale input step".
> I intend to attach a script to the pre-commit hook. Amongst many QA
> checks that it will make are that the document has been changed, and the
> changes are only within certain bounds.
> If I use an OpenOffice text table for instance, I should be able to make
> sure that one row to this table has been added, and that that row
> contains three columns, the two that contain the revision number and
> commit date are empty, and that at least there is some text in the
> > This wrapper script will probably open your editor of choice, and
> > always start on some basic template.
> I can understand where you're coming from here as I had considered it
> briefly myself. Although I think having an editor open at the time the
> changes are committed sounds like a nice way to cater for entering
> rationale, it forces the developer to enter the rationale quickly. This
> aint so good. The developer should consider that the justification for a
> change is at least as important as the change itself.
> > If you get sufficiently fancy, the template or form fields can be
> > based on a list of files returned from "svn status", and maybe even
> > list changed line numbers returned for each file by a diff,
> > presenting the diff lines for convenience of reference (but not
> > including them in the file directly).
> Gee, I salivate at the chance of getting this fancy. I might supply the
> list of files included in the change in the svn:log entry. The rest, I
> could put in each change rationale document. I'd love the document to
> have diff output that was as verbose as possible! Hmmm... maybe not that
> > Likewise, you may want to wrap any "svn log" command to return some
> > method of opening any svn:log or rationale-file entry in the list
> > in your desired editor/viewer.
> Hmmm... not too sure what you are driving at here. I'd love an
basically - if you are going to store this much meta-information - make
sure you can read it later
In my system, the change rationale documents are being versioned with
> the project source, so are available to be checked out along with the
> modules that are subject to possible change.
> > Once those tools are done, it shouldn't much matter whether that
> > rationale data is stored in svn:log or some other file or database.
> > svn:log is already there, so you might as well use it.
> Well, I have two beefs about using svn:log: I believe it isn't subject
> to version control, and I don't like the prospect of recording changes
> to all modules in one file, especially when a revision involves changing
> many code base files.
it isnt versioned, but each revision has its own svn:log property
Thank you for helping me decide what I should do. I'd really like to
> know if my knowledge of SVN appears wrong in anything I have so far
> said. If you're beginning to like the idea, I'd also love to hear from
> you too - that'll give me some impetus to go ahead with my plans.
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Jan 11 04:36:19 2007