Few advices & notes if you want to keep your DVCS repository: - when I've last tried it importing NH's sources in GitHub haven't worked properly. It was something with importing branches. - doing it with Mercurial and Bitbucket works like a charm. - synch-ing Mercurial with svn works well with hgsubversion extension.
I'm doing it for a while with NHibernate and NH.Contrib repositories and it works. It's very easy to keep your own versions and patches until they are applied (or not, but now you don't care). Cheers On Wed, Dec 15, 2010 at 5:33 PM, Aaron Boxer <[email protected]> wrote: > Well, these changes promise significant performance improvement for > distributed second > level cache, and also new features, so I would be surprised if the > patch is rejected. But, if it is, > I will do the following: > > 1) run git-svn on NH trunk, and place Git repo on GitHub > 2) add my changes in > 3) keep pulling in changes from trunk > 4) make a custom NH build for my application, from GitHub repo > > > > On Wed, Dec 15, 2010 at 11:08 AM, Fabio Maulo <[email protected]> > wrote: > > what happen if your proposal won't be applied and you think that it is > > fundamental for you ? > > > > -- > > Fabio Maulo > > > > > > El 15/12/2010, a las 11:35, Aaron Boxer <[email protected]> escribió: > > > >> so, I've submitted a patch to JIRA, and the changes are sizeable. Now, > >> while I wait for someone > >> to review the patch and perhaps check them into the trunk, I am > >> essentially not using source control: > >> if I change a file affected by the patch, I cannot make a commit and > >> store in a commit message why > >> I made the change. If the patch goes in, it will be a big ball of code > >> with no history; I will have to remember > >> what I changed and why, a long time after the fact. > >> > >> If I was using a DCVS, I could commit all I liked to my local repo, > >> storing up a history of my changes, and this would > >> be available when the changes were pulled in. > >> > >> This is very frustrating. I think it makes it a lot harder to develop > >> patches when you are not a committer. And it > >> reduces the quality of the review process, because the history is not > there. > >> > >> Gentlemen, the time has come for a better way! > > >
