Perhaps this is a another argument for versions on server/api code. One file to find changes is convenient. I think this makes sense for a version ChangeLog, which will change *much less* frequently than SCM revisions/commits, because versions grow slower than commits. Then you'll have general overview changes in the ChangeLog, which follows api/server versions and this we reside alongside frequent commit comments, which go where they belong in the SCM system. Seems like best of both worlds to me, unless how I phrased it made no sense... (possible :-D )
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nicolás Álvarez Sent: Thursday, October 25, 2012 11:47 AM To: Oliver Bock Cc: boinc_dev Subject: Re: [boinc_dev] Git commits: message formatting and atomicity=?utf- 8?B?LiAgICAu?= On 25/10/2012, at 09:02, Oliver Bock <[email protected]> wrote: > For the potential argument that you want to keep the change log > separate from the SCM tool: did you ever loose history because you > switched to another SCM system? No. Yes. Rom dropped the history from CVS days; the git repository starts at around SVN r8000. -- Nicolás _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
