Menu
▾
▴
Re: [Kaldi-developers] Testing Github repository
|
From: Jan T. <af...@ce...> - 2015-04-06 20:17:01
|
Alexander, can you send show us (i.e. how this is done on command-line level) how this is done? y. On Mon, Apr 6, 2015 at 3:59 PM, Alexander Solovets <aso...@gm...> wrote: > I would recommend to stick to SVN as long as possible just because > when the history is linear you can easily convert repository from one > VCS to another. When the git branching hell comes you'll have to stay > with it forever. On CMU Sphinx when a pull request is received, it > actually goes to SVN first and then is closed with the revision number > in the comment, like this > https://github.com/cmusphinx/sphinxtrain/pull/4. > > On Mon, Apr 6, 2015 at 8:04 PM, Jan Trmal <af...@ce...> wrote: > > Kirill and all, > > first, thanks for your comments and encouragement > > As it looks right now, we will have only single, trunk, branch in the > > repository (we might even delete the stable branch). > > During a few past days, I have imported the kaldi repository once more. > The > > reason was that if you select the project's licence during repository > > creation on github, github will commit some files into the repository > > (LICENCE file at least) and that messed up the commit history so that git > > svn rebase didn't work -- I had to do recursive merge every time before I > > called rebase and everything was getting out my control. There might be > easy > > fix for this, but the most straightforward way for me was to run the > > conversion again. After that, the svn rebase work smoothly (I have a cron > > job taking care of it now). > > > > During this week, I intend to do the conversion once more again and > > hopefully for the last time (i.e. after that, we will have an official > kaldi > > git repository mirroring changes from SVN) > > The current tentative plans for kaldi transition is: > > * first, for a few months, operate the github kaldi repo as an official > > mirror of svn. That means all commits will go to SVN and the less > > adventurous users (and possibly companies with more inflexible workflow) > can > > keep using SVN. This is to give us time to sort out the issues, write up > the > > docs and get familiar with git > > * after that, we can make the git repository primary and instead of > > mirroring SVN->GIT we will mirror GIT->SVN (note: I still have to figure > out > > if this is feasible -- but I think it is). This should -force- motivate > all > > users to switch to GIT > > * after that (or right after skipping the previous stage completely) keep > > only git and stop using and supporting SVN. > > > > y. > > > > > > > > > > On Mon, Apr 6, 2015 at 2:36 PM, Kirill Katsnelson > > <kir...@sm...> wrote: > >> > >> Totally true. Depending on the type of workflow that Kaldi developers > see, > >> there are up to 3 cloned repositories involved. This is what happens in > the > >> project I maintain (https://github.com/fsprojects/FsLexYacc). We do not > >> accept any other way to submit changes to the main repository (which is > a > >> bare repo in github) than using github's pull requests. Even people with > >> write access to the repo must follow this path. Since the pull request > may > >> only be generated in github between 2 branches on repos necessarily > stored > >> on gihub (although the branches may be in different repos, having a > common > >> history fork in the past), the patch submitter must have cloned the main > >> repo at some point. This is the clone #2. > >> > >> Since the submitter obviously has to do some hacking first, he clones > his > >> github clone #2 to a desktop, locally, and this is the clone #3. He > normally > >> pushes into a branch or the master "trunk," and, come time to send the > >> changes upstream, issues a pull request for a diff between clones #1 > and #2 > >> (or 2 points in history in #2). > >> > >> The only tricky part here is merging upstream changes into this train of > >> clones (analogous to "svn update") in such a way that the upstream > changes > >> would not show up in the resulting pull request. > >> > >> Another workflow would be allowing changes into the main trunk branch > "the > >> svn way." To me, the main benefit of having the pending commits (as pull > >> requests) inspected by the peers is lost in this workflow. But the > decision > >> is on Kaldi dev's I any case. > >> > >> It perhaps makes sense to write up a walk-through for first time git (or > >> github) users. I'd take on the task, but I need to play back the > >> step-by-step as I write, so I need time for the task. A workflow > decision > >> must be done first, however. There might also be an existing guide on > the > >> 'Net for those migrating from svn into the selected git workflow. > >> > >> -kkm > >> > >> > -----Original Message----- > >> > From: Phil Garner [mailto:Phi...@id...] > >> > Sent: 2015-04-05 0622 > >> > To: kal...@li... > >> > Subject: Re: [Kaldi-developers] Testing Github repository > >> > > >> > > So far, I pushed only the trunk and stable branch -- I'm not sure if > >> > > import of all sandboxes makes sense. > >> > > >> > If I understand the concept of sandboxes well, then in git they may > >> > better correspond to branches in user clones of the repository. That > >> > is, the person responsible for the sandbox clones the trunk repo and > >> > commits to a branch as they wish. Github makes this very easy. > >> > > >> > -- > >> > Phil Garner > >> > http://www.idiap.ch/~pgarner > >> > > >> > > >> > > ----------------------------------------------------------------------- > >> > ------- > >> > Dive into the World of Parallel Programming The Go Parallel Website, > >> > sponsored > >> > by Intel and developed in partnership with Slashdot Media, is your hub > >> > for all > >> > things parallel software development, from weekly thought leadership > >> > blogs to > >> > news, videos, case studies, tutorials and more. Take a look and join > >> > the > >> > conversation now. http://goparallel.sourceforge.net/ > >> > _______________________________________________ > >> > Kaldi-developers mailing list > >> > Kal...@li... > >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > >> > >> > ------------------------------------------------------------------------------ > >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > >> Develop your own process in accordance with the BPMN 2 standard > >> Learn Process modeling best practices with Bonita BPM through live > >> exercises > >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > >> event?utm_ > >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > >> _______________________________________________ > >> Kaldi-developers mailing list > >> Kal...@li... > >> https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > > > > > > ------------------------------------------------------------------------------ > > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > > Develop your own process in accordance with the BPMN 2 standard > > Learn Process modeling best practices with Bonita BPM through live > exercises > > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > > _______________________________________________ > > Kaldi-developers mailing list > > Kal...@li... > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > > > -- > Sincerely, Alexander > |
