I thought I would put my two cents worth in.
First off - I think the SVN commit guidelines are a good idea. I looked
at the KDE guidelines, and I think we can adapt these to meet our needs.
With the ChangeLogs - I'm not convinced yet. I am willing to change if
it is a benefit, but I don't see it yet.
Right now, as I work on the program, I update the ChangeLog as I work.
Since it may be several days an up to two dozen changes between commits,
operating this way helps me to keep track what I have done. Otherwise, I
would forget the changes by the time I actually make the commit. Using
the "svnci" script, change set is committed to svn, and the ChangeLog is
used to provide the log message.
I'm not sure I see the advantage of the change. It seems that I would
have to remember all the changes that I've made and record them when I
commit the message. Then we would use another script to convert the SVN
log to a ChangeLog.
It looks like the same amount of work. However, the first gives me the
advantage of allowing me to record my changes as I go, so I don't forget
them by the time I make a commit.
On Sat, 2007-03-24 at 12:51 -0700, Brian Matherly wrote:
> Alex wrote:
> >The ChangeLog is there to fulfill the requirements of the GPL . . .
> >The GPL cannot rely on any particular version control system . . .
> >Yes, it's not for laymen, but rather for anybody who wants . . .
> >Personally, I found changelog not to be a burden at all ever since . . .
> Stefan wrote:
> >Why not use a tool like (the svn equivalent of) cvs2cl?
> >. . . we use double booking for tracking of changes.
> Richard wrote:
> >the way we use the ChangeLog at present is a very tight interpretation .=
> >There are many GPL projects that rely on the svn logs . . .
> >We can always include a ChangeLog generated from the svn logs . . .
> >The svn log -v and svn log -d output is much more detailed . . .
> >when refactorying it is a bit of a pain . . .
> Gerald wrote:
> >I read the top of the changelog each time I do a svn update . . .
> Benny wrote:
> >what is the problem with doing svn log --limit 10 . . .
> This is EXACTLY the kind of conversation I was looking for. Thanks to eve=
ryone for your participation. One perspective I was completely lacking was =
that of the packagers. I also hadn't considered the GPL as having anything =
to do with it.=20
> Here are some notable links:
> The policy for the Gimp project:
> Gnome has a similar conversation going after switching to SVN:
> Official recommendations from GNU (note the text "Another alternative is =
to record change log information with a version
> control system such as RCS or CVS"):
> GNUCash has had a slimilar discussion. (This is a long thread):
> KDE's policy (There's a lot of good stuff in here):
> I would encourage those who use the ChangeLog to consider if there are be=
tter ways to accomplish the same task. Just because this is what we've alwa=
ys done does not mean it is best for us.
> I would also LOVE to see a commit policy on the Wiki (simliar to the KDE =
link above). It would help align the expectations of all developers of what=
process to use (even if everyone doesn't like it, at least they agree on w=
hat it is). It would also help me when someone asks me to commit some rando=
m patch, I can check it against the policy and use that as a basis if I dec=
line to commit the patch.
> Thanks again to everyone for your participation. This really is a great c=
ommunity to be a part of.
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
> opinions on IT & business topics through brief surveys-and earn cash
> Gramps-devel mailing list