Re: Turning cvs2{svn,git} into cvs2hg
Greg Ward <[email protected]>
| Newsgroups | gmane.comp.version-control.subversion.cvs2svn.devel |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Aug 4, 2009 at 5:08 PM, Michael Haggerty<[email protected]> wrote: >> BTW, what's the preferred way to send patches? > > My main preference is that the patches be bite-sized pieces, one > indivisible change per patch as far as possible. OK, will do. That should be quite manageable, except for hg_run_options.py and hg_output_option.py: I don't think there's any point in sending a blow-by-blow summary of every change I've made to those two modules. Unless you *really* want it. > It would also be great > if you would include suggested commit log messages formatted as > described in the Subversion hacking guide [1], though I'm not as picky > as the Subversion project. Funny: yeeeears ago, when I first started using svn (2000-01), I really wished there was a way to specify different commit messages for different files in the same revision. (Obviously a holdover from CVS-thought.) Thankfully, I have recovered from this, and totally embraced the changeset view of the world that git and Mercurial encourage. So imagine my surprise when I start looking at cvs2svn and svn's own logs, and see ... yes... there it is ... they supply different commit messages for different files in the same revision. Aieee! Ah well. I know well enough to stick to local custom when contributing to somebody else's project. ;-) Anyways: rather than hopefully confuse myself by using git to manage changes to a project that turns cvs into hg by way of a very svn-like intermediate representation, I think I'll just email patches to dev@cvs2svn. Keeping 3 version control systems in my head at once is quite enough, thank you. (If we're lucky, git-apply-patch (or whatever it's called) will be able to handle hg's email patch format.) Greg ------------------------------------------------------ http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2380821 To unsubscribe from this discussion, e-mail: [[email protected]].