ChangeLog and ChangeLog.old

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

ChangeLog and ChangeLog.old

Brian Matherly
I've been contributing to Gramps for some time now, and I have never been able to figure out the purpose of the ChangeLog file. I add entries to it every time I make a commit, but I have no idea why (other than status quo). I think we should get rid of it. Here are the reasons why.

1) It makes merging from one branch to another really difficult because there is invariably a conflict in the ChangeLog file which I have to resolve before I can commit the merge. (This happens whenever I fix a bug in gramps 2.2 and want to move the fix into gramps 2.3.

2) All the information in the ChangeLog is redundant if people add friendly comments when they commit to the repository (just run "svn log https://svn.sourceforge.net/svnroot/gramps/branches/gramps23 -v --limit 20" and see how silly it looks).

3) The ChangeLog is incredibly big.

4) The ChangeLog is too detailed to serve any practical use for a casual user who wants to know what changes they will see in the program. So it has to be interpreted by a developer before it can be published.

I'm open to discussion.

~Brian




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Alex Roitman
Brian,

On Mon, 2007-03-19 at 20:04 -0700, Brian Matherly wrote:
> I've been contributing to Gramps for some time now, and I have never been able to figure out the purpose of the ChangeLog file. I add entries to it every time I make a commit, but I have no idea why (other than status quo). I think we should get rid of it. Here are the reasons why.

The ChangeLog is there to fulfill the requirements of the GPL
that every contributor's changes be documented. In fact, the GPL
requires that every re-distribution clearly marks the changes.
We are constantly in the process of the redistribution of such changes.

> 1) It makes merging from one branch to another really difficult because there is invariably a conflict in the ChangeLog file which I have to resolve before I can commit the merge. (This happens whenever I fix a bug in gramps 2.2 and want to move the fix into gramps 2.3.

Yes. I tried to make a reasonable effort when I merged branches
in CVS. It turns out that svn has a tool that properly merges
changelogs from different branches. At worst, we get the same
change documented twice.

> 2) All the information in the ChangeLog is redundant if people add friendly comments when they commit to the repository (just run "svn log https://svn.sourceforge.net/svnroot/gramps/branches/gramps23 -v --limit 20" and see how silly it looks).

The GPL cannot rely on any particular version control system.
First, we distribute the tarballs and they do not contain any
history, just the static snapshot. Second, our SVN may one day
simply disappear from under us if e.g. sf.net folks change their
minds and decide to stop this service. While I don't expect this
to happen, it is possible, they don't owe us anything.

> 3) The ChangeLog is incredibly big.

We can rotate it. We have ChangeLog.old which is pre-2005 stuff.
It is easy to start a new one and then prepend the existing one
to the old changelog.

> 4) The ChangeLog is too detailed to serve any practical use for a casual user who wants to know what changes they will see in the program. So it has to be interpreted by a developer before it can be published.

Yes, it's not for laymen, but rather for anybody who wants (and can)
to track copyrighted content. Coincidentally, it is convenient
for many people, myself included: I open changelog and see
right away what people committed overnight. More than once
that helped me to identify problems and fix them before
they were ever released or I had a chance to notice them
in run time. I could do it by retrieving the comments from svn,
but when everything is in a single file it's very convenient.

Personally, I found changelog not to be a burden at all
ever since I switched to emacs. In emacs, there's a macro
(C-X 4 a) that, when executed in a source file, automatically
adds a proper changelog entry, including module name and
even a class and a function name the cursor was in. I am sure
other editors can be configured to do that as well.

My 2 cents,
Alex

--
Alexander Roitman   http://www.gramps-project.org

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Richard Taylor-2
On Tuesday 20 March 2007 06:00, Alex Roitman wrote:

> Brian,
>
> On Mon, 2007-03-19 at 20:04 -0700, Brian Matherly wrote:
> > I've been contributing to Gramps for some time now, and I have never been
> > able to figure out the purpose of the ChangeLog file. I add entries to it
> > every time I make a commit, but I have no idea why (other than status
> > quo). I think we should get rid of it. Here are the reasons why.
>
> The ChangeLog is there to fulfill the requirements of the GPL
> that every contributor's changes be documented. In fact, the GPL
> requires that every re-distribution clearly marks the changes.
> We are constantly in the process of the redistribution of such changes.
>

Whilst I agree with the reading of the GPL, the way we use the ChangeLog at
present is a very tight interpretation of the GPL requirements. There are
many GPL projects that rely on the svn logs to fulfill this requirement (or
more likely don't even know the requirement exists.)

> > 1) It makes merging from one branch to another really difficult because
> > there is invariably a conflict in the ChangeLog file which I have to
> > resolve before I can commit the merge. (This happens whenever I fix a bug
> > in gramps 2.2 and want to move the fix into gramps 2.3.
>
> Yes. I tried to make a reasonable effort when I merged branches
> in CVS. It turns out that svn has a tool that properly merges
> changelogs from different branches. At worst, we get the same
> change documented twice.
>
> > 2) All the information in the ChangeLog is redundant if people add
> > friendly comments when they commit to the repository (just run "svn log
> > https://svn.sourceforge.net/svnroot/gramps/branches/gramps23 -v --limit
> > 20" and see how silly it looks).
>
> The GPL cannot rely on any particular version control system.
> First, we distribute the tarballs and they do not contain any
> history, just the static snapshot. Second, our SVN may one day
> simply disappear from under us if e.g. sf.net folks change their
> minds and decide to stop this service. While I don't expect this
> to happen, it is possible, they don't owe us anything.
>

Don't we take backups of the svn?
We can always include a ChangeLog generated from the svn logs in the tarball.

> > 3) The ChangeLog is incredibly big.
>
> We can rotate it. We have ChangeLog.old which is pre-2005 stuff.
> It is easy to start a new one and then prepend the existing one
> to the old changelog.
>
> > 4) The ChangeLog is too detailed to serve any practical use for a casual
> > user who wants to know what changes they will see in the program. So it
> > has to be interpreted by a developer before it can be published.
>
> Yes, it's not for laymen, but rather for anybody who wants (and can)
> to track copyrighted content. Coincidentally, it is convenient
> for many people, myself included: I open changelog and see
> right away what people committed overnight. More than once
> that helped me to identify problems and fix them before
> they were ever released or I had a chance to notice them
> in run time. I could do it by retrieving the comments from svn,
> but when everything is in a single file it's very convenient.
>

I agree that it is useful. The question I think is: is it sufficiently useful
to warrant the effort in maintaining it. The svn log -v and svn log -d output
is much more detailed and guaranteed to be accurate.

> Personally, I found changelog not to be a burden at all
> ever since I switched to emacs. In emacs, there's a macro
> (C-X 4 a) that, when executed in a source file, automatically
> adds a proper changelog entry, including module name and
> even a class and a function name the cursor was in. I am sure
> other editors can be configured to do that as well.
>

When working on small changes it is not too bad, when refactorying it is a bit
of a pain. The spirit of the GPL requirements is that it should be possible
to track the copyright of every line of code. It is not possible to do that
from the ChangeLog, it is possible from the svn log.

My vote would be to generate the ChangeLog file from svn log when we export a
tarball and have rules that enforce sensible svn log messages.

But I do not feel particularly strongly either way.

Regards

Richard

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Stefan Björk
In reply to this post by Alex Roitman
Alex,

> The ChangeLog is there to fulfill the requirements of the GPL
> that every contributor's changes be documented. In fact, the GPL
> requires that every re-distribution clearly marks the changes.

Why not use a tool like (the svn equivalent of) cvs2cl? Certainly, Brian
has a point there - we use double booking for tracking of changes.

Stefan


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Gerald Britton-2
I read the top of the changelog each time I do a svn update, so I'd
like to see it remain

On 3/20/07, Stefan Björk <[hidden email]> wrote:

> Alex,
>
> > The ChangeLog is there to fulfill the requirements of the GPL
> > that every contributor's changes be documented. In fact, the GPL
> > requires that every re-distribution clearly marks the changes.
>
> Why not use a tool like (the svn equivalent of) cvs2cl? Certainly, Brian
> has a point there - we use double booking for tracking of changes.
>
> Stefan
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

bm-7
Gerald,

what is the problem with doing

svn log --limit 10

Does that not give you the information you want?

Benny

Quoting Gerald Britton <[hidden email]>:

> I read the top of the changelog each time I do a svn update, so I'd
> like to see it remain
>
> On 3/20/07, Stefan Björk <[hidden email]> wrote:
>> Alex,
>>
>> > The ChangeLog is there to fulfill the requirements of the GPL
>> > that every contributor's changes be documented. In fact, the GPL
>> > requires that every re-distribution clearly marks the changes.
>>
>> Why not use a tool like (the svn equivalent of) cvs2cl? Certainly, Brian
>> has a point there - we use double booking for tracking of changes.
>>
>> Stefan
>>
>>
>> ------------------------------------------------------------------------
-
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID
=DEVDEV
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y
our
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=
DEVDEV
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Brian Matherly
In reply to this post by Brian Matherly
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 everyone 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.

Here are some notable links:

The policy for the Gimp project:
http://lists.xcf.berkeley.edu/lists/gimp-docs/2007-March/000697.html

Gnome has a similar conversation going after switching to SVN:
http://uwstopia.nl/blog/2006/12/gnome-changelog-policy

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"):
http://www.gnu.org/prep/standards/html_node/Change-Logs.html

GNUCash has had a slimilar discussion. (This is a long thread):
http://lists.gnucash.org/pipermail/gnucash-devel/2005-December/014965.html

KDE's policy (There's a lot of good stuff in here):
http://developer.kde.org/policies/commitpolicy.html

I would encourage those who use the ChangeLog to consider if there are better ways to accomplish the same task. Just because this is what we've always 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 what it is). It would also help me when someone asks me to commit some random patch, I can check it against the policy and use that as a basis if I decline to commit the patch.

Thanks again to everyone for your participation. This really is a great community to be a part of.

~Brian




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Richard Taylor-2
Brian

This is a level of research that I can't compete with :-)

I like the idea of a 'commit policy' along the lines of the KDE one.

I was also wondering about something else, do we have the ability of add svn
hook scripts? If we do it might be possible to a 'commit hook' that
automatically added the commit log message to the ChangeLog file. I am not
sure about the details of this, I have never written a commit hook that made
a change to the files, but if it were possible it would satisfy both camps.
We would only need to write the details of the commit once, in the svn commit
log message, and we would have the ChangeLog entries for those that find them
useful.

Just a thought.

Richard

On Saturday 24 March 2007 19:51, 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
> everyone 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.
>
> Here are some notable links:
>
> The policy for the Gimp project:
> http://lists.xcf.berkeley.edu/lists/gimp-docs/2007-March/000697.html
>
> Gnome has a similar conversation going after switching to SVN:
> http://uwstopia.nl/blog/2006/12/gnome-changelog-policy
>
> 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"):
> http://www.gnu.org/prep/standards/html_node/Change-Logs.html
>
> GNUCash has had a slimilar discussion. (This is a long thread):
> http://lists.gnucash.org/pipermail/gnucash-devel/2005-December/014965.html
>
> KDE's policy (There's a lot of good stuff in here):
> http://developer.kde.org/policies/commitpolicy.html
>
> I would encourage those who use the ChangeLog to consider if there are
> better ways to accomplish the same task. Just because this is what we've
> always 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
> what it is). It would also help me when someone asks me to commit some
> random patch, I can check it against the policy and use that as a basis if
> I decline to commit the patch.
>
> Thanks again to everyone for your participation. This really is a great
> community to be a part of.
>
> ~Brian
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Brian Matherly
In reply to this post by Brian Matherly
Richard,

>I was also wondering about something else, do we have the ability of add svn
>hook scripts? If we do it might be possible to a 'commit hook' that
>automatically added the commit log message to the ChangeLog file. I am not
>sure about the details of this, I have never written a commit hook that made
>a change to the files, but if it were possible it would satisfy both camps.
>We would only need to write the details of the commit once, in the svn commit
>log message, and we would have the ChangeLog entries for those that find them
>useful.

I don't know if Sourceforge allows us to add hook scripts. If they did, it would be great. If nothing else, we could add a script that requires a commit message (right now, it's optional).

There are also Python and PHP bindings for SVN. So it would be easy to write a script that generates a ChangeLog file from the svn logs.

~Brian



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Don Allingham
In reply to this post by Brian Matherly
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.

Don

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 everyone 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.
>
> Here are some notable links:
>
> The policy for the Gimp project:
> http://lists.xcf.berkeley.edu/lists/gimp-docs/2007-March/000697.html
>
> Gnome has a similar conversation going after switching to SVN:
> http://uwstopia.nl/blog/2006/12/gnome-changelog-policy
>
> 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"):
> http://www.gnu.org/prep/standards/html_node/Change-Logs.html
>
> GNUCash has had a slimilar discussion. (This is a long thread):
> http://lists.gnucash.org/pipermail/gnucash-devel/2005-December/014965.html
>
> KDE's policy (There's a lot of good stuff in here):
> http://developer.kde.org/policies/commitpolicy.html
>
> I would encourage those who use the ChangeLog to consider if there are better ways to accomplish the same task. Just because this is what we've always 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 what it is). It would also help me when someone asks me to commit some random patch, I can check it against the policy and use that as a basis if I decline to commit the patch.
>
> Thanks again to everyone for your participation. This really is a great community to be a part of.
>
> ~Brian
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Richard Taylor-2
These are the types of discussions that can run and run ...

On Sunday 25 March 2007 22:29, Don Allingham wrote:
> 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.
>

I think that these guidelines ought to encourage developers to cite Mantis
issue numbers in the ChangeLog if they are working on reported bugs.

> 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.
>

Which 'svnci' script are you using? Google points me to 2 different ones (one
in perl (yuk) and one in Ruby).

> 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.

If I can easily automate the 'write Changelog entries, convert to svn log
message" work flow, then I too can't see much point in the change. The only
problem I have now is how to automate that in Eclipse rather than emacs :-)

Regards

Richard


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Don Allingham
On Mon, 2007-03-26 at 07:32 +0000, Richard Taylor wrote:
>
> Which 'svnci' script are you using? Google points me to 2 different ones (one
> in perl (yuk) and one in Ruby).
>

Actually, this is a simple shell script. I've attached it. Both Alex and
I use this.

Don


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

svnci (1K) Download Attachment
signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Don Allingham
And I should probably let you know that it needs the "patchutils"
package to be installed so that it can find "filterdiff"

Don

On Mon, 2007-03-26 at 06:06 -0600, Don Allingham wrote:

> On Mon, 2007-03-26 at 07:32 +0000, Richard Taylor wrote:
> >
> > Which 'svnci' script are you using? Google points me to 2 different ones (one
> > in perl (yuk) and one in Ruby).
> >
>
> Actually, this is a simple shell script. I've attached it. Both Alex and
> I use this.
>
> Don
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

bm-7
I added this to the wiki for future reference and developers (and attached the
svnci script to the page):

http://www.gramps-project.org/wiki/index.php?title=Brief_introduction_to_SVN#The_svnci_script

I use svnci myself, but it's been a while, so I might have made an
error in the
usage. If so, please correct.

Concerning this, svnci can probably be changed, so that the difference in a
standard file is used for the message instead of the Changelog. If you make
changes in Changelog as you go, doing 'svn up' in between might garble that up
somewhat I suppose. Apart from some core developers, I suspect people do a lot
of svn up before committing a total changeset.

Benny

Quoting Don Allingham <[hidden email]>:

> And I should probably let you know that it needs the "patchutils"
> package to be installed so that it can find "filterdiff"
>
> Don
>
> On Mon, 2007-03-26 at 06:06 -0600, Don Allingham wrote:
>> On Mon, 2007-03-26 at 07:32 +0000, Richard Taylor wrote:
>> >
>> > Which 'svnci' script are you using? Google points me to 2
>> different ones (one
>> > in perl (yuk) and one in Ruby).
>> >
>>
>> Actually, this is a simple shell script. I've attached it. Both Alex and
>> I use this.
>>
>> Don
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________ Gramps-devel mailing
>> list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Brian Matherly
In reply to this post by Brian Matherly
Don,

>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 would really encourage you to change this practice. SVN has some subtle differences from CVS that you can use to your advantage if you know how they work.

One difference is that SVN commits a changeset. That means that when you commit 5 files, they are all associated. Individual files don't have their own version like in CVS.
Another difference is that commits are atomic. That means that when you commit 5 files, if one fails, they all fail.

You can use these features to your advantage by always committing each change individually - even if that change spans multiple files. This is especially important when fixing bugs because you want each bug fix to be represented by a single commit. This way, it is easy to merge the bugfix into another branch.

Here's how the KDE policy words it:


    Make "atomic" commits.


    SVN
has the ability to commit more than one file at a time. Therefore,
please commit all related changes in multiple files, even if they span
over multiple directories at the same time in the same commit. This
way, you ensure that SVN stays in a compileable state before and after
the commit.



Sometimes I am in the middle of something big, and then I want to make a small, unrelated change before I finish what I'm in the middle of. When this happens, I just quickly create another working copy in another location, make the small change, and commit that. Then I can resume my work in the other working copy.

I've also taken to always creating a new entry in the ChangeLog for every commit (changeset). I feel like this helps to keep them from getting mixed up with each other.



Just some friendly suggestions.


~Brian




 




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Brian Matherly
In reply to this post by Brian Matherly
>> Which 'svnci' script are you using? Google points me to 2 different ones (one
>> in perl (yuk) and one in Ruby).
>>
>
>Actually, this is a simple shell script. I've attached it. Both Alex and
>I use this.
>
>Don

Does anyone know if there is a similar script for Windows or Eclipse? That's where I do all my development.

~Brian




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLog and ChangeLog.old

Don Allingham
In reply to this post by Brian Matherly
Actually, I understand the concept of changesets. My problem is that I
can be working on a particular feature addition or bug report for
several days at a time across multiple files. Intermediately editing the
ChangeLog allows me to keep track of what I've been doing over the past
several days.

Don

On Mon, 2007-03-26 at 20:11 -0700, Brian Matherly wrote:

> Don,
>
> >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 would really encourage you to change this practice. SVN has some subtle differences from CVS that you can use to your advantage if you know how they work.
>
> One difference is that SVN commits a changeset. That means that when you commit 5 files, they are all associated. Individual files don't have their own version like in CVS.
> Another difference is that commits are atomic. That means that when you commit 5 files, if one fails, they all fail.
>
> You can use these features to your advantage by always committing each change individually - even if that change spans multiple files. This is especially important when fixing bugs because you want each bug fix to be represented by a single commit. This way, it is easy to merge the bugfix into another branch.
>
> Here's how the KDE policy words it:
>
>
>     Make "atomic" commits.
>
>
>     SVN
> has the ability to commit more than one file at a time. Therefore,
> please commit all related changes in multiple files, even if they span
> over multiple directories at the same time in the same commit. This
> way, you ensure that SVN stays in a compileable state before and after
> the commit.
>
>
>
> Sometimes I am in the middle of something big, and then I want to make a small, unrelated change before I finish what I'm in the middle of. When this happens, I just quickly create another working copy in another location, make the small change, and commit that. Then I can resume my work in the other working copy.
>
> I've also taken to always creating a new entry in the ChangeLog for every commit (changeset). I feel like this helps to keep them from getting mixed up with each other.
>
>
>
> Just some friendly suggestions.
>
>
> ~Brian
>
>
>
>
>  
>
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (196 bytes) Download Attachment