From: Victor B. <vb...@gm...> - 2008-10-27 07:21:09
|
Hi all, The core dev team has been considering Git for a while now. Several of the developers have been running a local Git repository that they use to create their branches and push the changes to the central SVN using git-svn. We are now considering moving completely to git. The git repository will be hosted on our server rather than in Sourceforge. We are considering several ways of setting up our git repository(ies) and how we support the following: 1. Ability for developers to check-in to their branch/repository so that the code is available for others to pull / code review. 2. Ability for developers to pull patches from contributors. 3. Ability for multiple developers to work together on a feature and pull from each other. 4. Ability for the community to pull features from each other or from developer branches. 5. Implement a build process which gets the latest code on the supported branches and packages downloadable daily releases (assuming there is at least 1 check-in). We would like to open the forum to get feedback on the following: 1. The idea of moving to Git. 2. The best way to structure our git repository / repositories, branches, etc. *** FOR WINDOWS USERS *** For contributors / developers using Windows, there is a Git version for Windows which works fine for interacting with native git, but it is not as good for git-svn since there are some dependency on svn perl libraries that don't work well under Windows. Hence, by moving to a real git repository, such problem should go away. Personally, I'm a Windows user, after a lot of investigations I found that the following environment that worked best for me: 1. Windows Vista with 4 GB 2. VirtualBox VM with 1GB RAM + 128MB Video RAM running Fedora / Ubuntu. 3. Run the VM in seamless mode. This allows having one desktop with some windows from MS Windows and others from Linux with shared clipboard, shared folders, etc. I've found the above setup to be better than cygwin or running ported applications. Regards, Victor |
From: Jeferson O. <jef...@gm...> - 2008-10-27 10:15:49
|
On Mon, Oct 27, 2008 at 4:21 AM, Victor Boctor wrote: > Hi all, Hi Victor! > The core dev team has been considering Git for a while now. Just curious: what features does Git has that is motivating its adoption in substitution of Subversion? -- Regards, Jeferson Oliveira Brazil |
From: Victor B. <vb...@gm...> - 2008-10-27 10:27:47
|
Hi Jeferson, On Mon, Oct 27, 2008 at 3:13 AM, Jeferson Oliveira <jef...@gm...> wrote: > On Mon, Oct 27, 2008 at 4:21 AM, Victor Boctor wrote: >> Hi all, > > Hi Victor! > > >> The core dev team has been considering Git for a while now. > > Just curious: what features does Git has that is motivating its > adoption in substitution of Subversion? Checkout the following presentation on YouTube: http://www.youtube.com/watch?v=4XpnKHJAok8 Regards, Victor |
From: Juliano F. R. <ml...@ju...> - 2008-10-27 14:36:28
|
Victor Boctor wrote: > Checkout the following presentation on YouTube: > http://www.youtube.com/watch?v=4XpnKHJAok8 I wonder what Linus did to make so many people lose their rational thinking when watching this specific presentation. Every time a project leader cames with this argument to justify the switch to Git it hits me in the nerve. I would be lying if I said this presentations wasn't the primary reason of my disdain against Git. Victor, try to visualize this: You are the project leader of a great and famous Issue Tracker system. Everything is going well, everyone is happy, your users are satisfied, etc. But it is a Centralized Issue Tracker, you need a central server, with a central database, and the connection of the Issue Tracker with the core development repository is very minimal. Then you hear about a new concept called Distributed Issue Tracking [1]. It makes a lot of sense, you fix bugs in distributed developer branches, but these bugs are only fixed for everyone else when you sync (push/pull) to/from other developers, or the central repository. And you realize that your project could improve a lot and become a Distributed Issue Tracker, and that would be great, since you have a working, well-designed, robust system with a lot of users and live feedback. When you are planning the development of the next version of your Issue Tracker system, with full support for distributed development integration, another, very prominent open-source developer gives a presentation about how good is Distributed Issue Tracking and how bad is Centralized Issue Tracking, stressfully disdaining the model used by your current project, *citing your project by name*, pretty much comparing your project to a worthless pile of sh_t. For some reason, people watch this presentation and don't realize how grossly unethical it is for one open-source developer to completely destroy another open-source project, specially using of his popularity. Instead of people going "hey, He may be a cool guy and so, but he did way over the line now" and "well, everyone knows that that issue tracker is very good and well-matured, despite what He said, let's join that team and help them going to this new model"; people actually start joining the mailing lists and IRC channel of the Issue Tracker to troll, calling you and your other developers idiots, saying that your project is a piece of sh_t, etc. In the end, you and the other developers of your project become *very* distressed with the situation, because the number of irrational trolls is way bigger than the number of contributors willing to help you. You lose a lot of time that you could be working in your project dealing with the trolls, and the interest in making your Issue Tracker a Distributed Issue Tracker pretty much vanishes. In fact, your interest in Issue Trackers at all is severely hurt in the process. What would have became a healthy open-source ecosystem, with multiple projects sharing ideas and ideals, becomes a flamewar field, where only a single one always win, and it is not you. Sorry for the long post. Best regards, Juliano. [1] http://www.distract.wellquite.org/doku.php http://erlangish.blogspot.com/2007/05/distributed-bug-tracking.html http://www.selenic.com/pipermail/mercurial/2008-January/016388.html http://lwn.net/Articles/281849/ -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead. |
From: Victor B. <vb...@gm...> - 2008-10-27 15:55:48
|
Hi Juliano, Interesting points, see my replies inline. The aim of moving from SVN is to get the benefits of a distributed source control where developers can work offline, manage multiple branches, easily merge changes, apply patches and get contributions from the community. However, we will need to make the right choice of the source control system to use, git is just one option, but I'm open for the other options if they are going to meet our needs and are easier to use by our contributors (both using Linux / Windows). I will leave the details of why move to the other fork of this thread. On Mon, Oct 27, 2008 at 7:05 AM, Juliano F. Ravasi <ml...@ju...> wrote: > Victor Boctor wrote: >> Checkout the following presentation on YouTube: >> http://www.youtube.com/watch?v=4XpnKHJAok8 > > I wonder what Linus did to make so many people lose their rational > thinking when watching this specific presentation. Every time a project > leader cames with this argument to justify the switch to Git it hits me > in the nerve. I would be lying if I said this presentations wasn't the > primary reason of my disdain against Git. [Victor] Just for the record, I really didn't like Linus' attitude in this presentation. > Victor, try to visualize this: You are the project leader of a great and > famous Issue Tracker system. Everything is going well, everyone is > happy, your users are satisfied, etc. But it is a Centralized Issue > Tracker, you need a central server, with a central database, and the > connection of the Issue Tracker with the core development repository is > very minimal. > > Then you hear about a new concept called Distributed Issue Tracking [1]. > It makes a lot of sense, you fix bugs in distributed developer branches, > but these bugs are only fixed for everyone else when you sync > (push/pull) to/from other developers, or the central repository. And you > realize that your project could improve a lot and become a Distributed > Issue Tracker, and that would be great, since you have a working, > well-designed, robust system with a lot of users and live feedback. > > When you are planning the development of the next version of your Issue > Tracker system, with full support for distributed development > integration, another, very prominent open-source developer gives a > presentation about how good is Distributed Issue Tracking and how bad is > Centralized Issue Tracking, stressfully disdaining the model used by > your current project, *citing your project by name*, pretty much > comparing your project to a worthless pile of sh_t. > > For some reason, people watch this presentation and don't realize how > grossly unethical it is for one open-source developer to completely > destroy another open-source project, specially using of his popularity. [Victor] I totally agree, as mentioned above, I really didn't like his attitude. > Instead of people going "hey, He may be a cool guy and so, but he did > way over the line now" and "well, everyone knows that that issue tracker > is very good and well-matured, despite what He said, let's join that > team and help them going to this new model"; people actually start > joining the mailing lists and IRC channel of the Issue Tracker to troll, > calling you and your other developers idiots, saying that your project > is a piece of sh_t, etc. [Victor] I'm totally against bad mouthing other projects. > In the end, you and the other developers of your project become *very* > distressed with the situation, because the number of irrational trolls > is way bigger than the number of contributors willing to help you. You > lose a lot of time that you could be working in your project dealing > with the trolls, and the interest in making your Issue Tracker a > Distributed Issue Tracker pretty much vanishes. In fact, your interest > in Issue Trackers at all is severely hurt in the process. > > What would have became a healthy open-source ecosystem, with multiple > projects sharing ideas and ideals, becomes a flamewar field, where only > a single one always win, and it is not you. [Victor] I guess we are on the same page. > Sorry for the long post. > > Best regards, > Juliano. > > > [1] http://www.distract.wellquite.org/doku.php > http://erlangish.blogspot.com/2007/05/distributed-bug-tracking.html > http://www.selenic.com/pipermail/mercurial/2008-January/016388.html > http://lwn.net/Articles/281849/ > > -- > Juliano F. Ravasi ·· http://juliano.info/ > 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 > > "A candle loses nothing by lighting another candle." -- Erin Majors |
From: David A. D. <de...@gn...> - 2008-10-27 16:07:52
|
On Mon, 2008-10-27 at 08:55 -0700, Victor Boctor wrote: > Interesting points, see my replies inline. The aim of moving from SVN > is to get the benefits of a distributed source control where > developers can work offline, manage multiple branches, easily merge > changes, apply patches and get contributions from the community. You can do this now, without having to deal with moving the upstream repository from Subversion to Git. Just use git in your local tree, make your commits and merges there, and then commit to Subversion once you have you working changeset ready to push. Lots of people that manage thousands of merges and commits do it this way, including Linus, Randall Schwartz and plenty of others. Granted, Linus uses Git exclusively for the kernel because he wrote it, but on projects where he does NOT control the upstream repo, he uses git to manage his work locally and pushes to the upstream repo in the format they require. There is no reason to change the upstream repo to leverage the power of git. |
From: John R. <jr...@le...> - 2008-10-27 17:01:03
|
David A. Desrosiers wrote: > On Mon, 2008-10-27 at 08:55 -0700, Victor Boctor wrote: >> Interesting points, see my replies inline. The aim of moving from SVN >> is to get the benefits of a distributed source control where >> developers can work offline, manage multiple branches, easily merge >> changes, apply patches and get contributions from the community. > > You can do this now, without having to deal with moving the upstream > repository from Subversion to Git. Just use git in your local tree, make > your commits and merges there, and then commit to Subversion once you > have you working changeset ready to push. Lots of people that manage > thousands of merges and commits do it this way, including Linus, Randall > Schwartz and plenty of others. > > Granted, Linus uses Git exclusively for the kernel because he wrote it, > but on projects where he does NOT control the upstream repo, he uses git > to manage his work locally and pushes to the upstream repo in the format > they require. > > There is no reason to change the upstream repo to leverage the power of > git. Right, this is exactly what I already do, but we are limited in this because: a) every developer must make their own git-svn clone, which takes ages with SF.net's slow SVN servers b) sharing commits/branches with other developers is not easy c) because of b, any sort of code review system would require branching and such, which is a pain and less friendly in SVN than in Git. I'll post more about what Git will gain us in another email to the list. -- John Reese LeetCode.net |
From: David A. D. <de...@gn...> - 2008-10-27 17:28:52
|
On Mon, 2008-10-27 at 13:00 -0400, John Reese wrote: > a) every developer must make their own git-svn clone, which takes ages > with SF.net's slow SVN servers Why does it take ages? A checkout is a one-time, atomic operation from their servers to you. Nothing at all should be "stored" on the SVN servers at SF.net, with respect to git's existence at all. It is, and should always be, 100% transparent to the repository side. > b) sharing commits/branches with other developers is not easy Again, simple because you simply create a branch in your local repo and point people to that so they can 'git pull' from you, or you merge and commit to svn, branch that and point people to that. Once that is no longer needed, destroy the branch (or did sf.net's admins disable that functionality too? > c) because of b, any sort of code review system would require > branching and such, which is a pain and less friendly in SVN than in > Git. Which is precisely why svk and or gitk exist, to allow and leverage the better, more-robust merging and review that needs to happen. None of this has anything to do with the repository side, however. You don't review code in the repository, you review code in a local branch or trunk copy. I still fail to see what moving to git, server-side gains for anyone, over what you already get with svn + svk + git now. I'm all ears. |
From: John R. <jr...@le...> - 2008-10-27 17:42:12
|
David A. Desrosiers wrote: > On Mon, 2008-10-27 at 13:00 -0400, John Reese wrote: >> a) every developer must make their own git-svn clone, which takes ages >> with SF.net's slow SVN servers > > Why does it take ages? A checkout is a one-time, atomic operation from > their servers to you. Nothing at all should be "stored" on the SVN > servers at SF.net, with respect to git's existence at all. It is, and > should always be, 100% transparent to the repository side. It takes ages because `git-svn clone` pulls the history of the SVN tree (half the point of using DVCS), which means pulling one revision at a time, and because SF.net's SVN servers are forever overloaded, and because two-way integration requires using HTTPS, it means that it takes ages even for Git to only pull the history of the 1.1.x and 1.2.x trees. >> b) sharing commits/branches with other developers is not easy > > Again, simple because you simply create a branch in your local repo and > point people to that so they can 'git pull' from you, or you merge and > commit to svn, branch that and point people to that. Once that is no > longer needed, destroy the branch (or did sf.net's admins disable that > functionality too? > >> c) because of b, any sort of code review system would require >> branching and such, which is a pain and less friendly in SVN than in >> Git. > > Which is precisely why svk and or gitk exist, to allow and leverage the > better, more-robust merging and review that needs to happen. None of > this has anything to do with the repository side, however. You don't > review code in the repository, you review code in a local branch or > trunk copy. Every time I've tried to use SVK, I've either a) borked my local checkout because SVK tried to do the wrong thing, b) borked the remote repository because SVK failed to handle DVCS-tyle syncing, or c) gotten too frustrated because SVK would refuse to let me keep any sort of decent repo history on my local machine. Anywho, see my other post to the list that details why I feel a DVCS is important. -- John Reese LeetCode.net |
From: John R. <jr...@le...> - 2008-10-27 17:35:37
|
Jeferson Oliveira wrote: > Just curious: what features does Git has that is motivating its > adoption in substitution of Subversion? The biggest feature in my mind that a DVCS tool gives you over the use of SVN is the following features: a) you have the entire project history on your local machine, which means you can do all of the following quickly and without needing to talk to a remote, central server (which for SF.net is damn slow): - View a log of commits - View commit changesets / diffs - Create local, versioned testing branches - Commit local changes to any branch b) branches are cheap, private, and mergeable, which lets you do the following: - Create a local feature/topic branch and begin working without needing to push incomplete/untested/unready changes to the remote server - Share local branches between developers without central server - Allow branches to follow master/trunk using rebase type of tools - Merge branches with each other automatically by the tool and without the need for special merge commits - No need to run slow `svn switch` or change to different file path to change what branch you're working on c) with cheap, efficient, and easily mergeable branches, we can begin to use staging/edge/testing branches for commits, which can then be reviewed by others before being merged to master/trunk d) we allow others to begin contributing to the project without needing to be granted commit access beforehand: - Commits, or branch histories, can be passed around without needing to deal with diff/patch commands; the DVCS tool will do it all for you - Local changes to the project can be kept in a private tracking branch that gets constantly rebased on master/trunk, allowing a person/company to maintain a history of changes without dealing with the mess of manual diffing/patching after each update from central repo. As to why I feel Git is a better option than others: a) local, inline branching is more intuitive and easier to work with than the branching methods used by Mercurial and Bazaar: - `git co <branch>` is far more efficient of a workflow than having to have a separate checkout of every branch I want to work on in a different top level directory - `git merge|rebase <branch>` and `git cherry-pick <revision>` work far more easily when all of your branches are kept in the same repository and top level directory, as compared to the basic equivalents in Bz/Hg b) the index (bad name for what should be called the 'staging area') is incredibly powerful once you learn how it works and how to make use of it: - When I start working on multiple things at once, and then decide that I need to break it up into separate commits or branches, a series of `git add -p` and `git commit` commands allow me to easily divide all of my uncommitted changes into a set of distinct patches; then with the use of `git rebase -i` and `git cherry-pick`, I can reorder those commits into a more logical order, and then pull specific commits to other branches as needed c) more as a personal preference, I find that Git is far more developer-oriented than Hg/Bz, because it gives you the power and the flexibility to use Git in a manner that best suits your own style of development. - It's a lot like comparing editors such as Emacs and Vi/Vim to ones like Nano, GEdit, and Kate: Git/Vim is at first less user-friendly and intuitive than Mercurial/GEdit (which IMO is more like distributed SVN than anything), but when you put the effort into learning how to use the tool, then you find more and more that Git can do exactly what you want and need it to do, while Mercurial and friends are less complicated and easier to learn. Now, obviously I'm a big fan of Git; I've been using it for almost a year now, and I've never had any regrets, or had any troubles with it all. I also use Linux on all my machines, so I have no experience with trying to set up Git on Windows. However, I do know that as of Git 1.6, the Msysgit team and their changes have been integrated into the mainline Git team and repository, so that future releases "should" be easier to get running on a Microsoft platform. Also, GitCheetah is a decent graphical took for working with Git, in the same ideals as TortoiseSVN and TortoiseHg, but there are also many other graphical front ends for Git as well. I personally would rather switch to *any* DVCS tool than stick with using SVN hosted by SourceForge, but I'd also *greatly* prefer that the DVCS choice be Git. Your mileage may vary; this is just my not-so-humble opinion; question/ignore/flame/berate me as necessary; etc. -- John Reese LeetCode.net |
From: Juliano F. R. <ml...@ju...> - 2008-10-30 04:12:55
|
John Reese wrote: > a) you have the entire project history on your local machine, which > means you can do all of the following quickly and without needing to > talk to a remote, central server (which for SF.net is damn slow): > - View a log of commits > - View commit changesets / diffs > - Create local, versioned testing branches > - Commit local changes to any branch It is important to not confuse concepts of distributed version control to features that are commonly found in DVCSes. Most of these features, including local commits are not strictly really tied to the distributed model. Legend says that Subversion will have local history and local commits, before becoming a distributed VCS. > c) with cheap, efficient, and easily mergeable branches, we can begin to > use staging/edge/testing branches for commits, which can then be > reviewed by others before being merged to master/trunk Nothing blocks you from doing this with Subversion, or any other VCS for that matter. Not as easy at least, sure. > As to why I feel Git is a better option than others: > > a) local, inline branching is more intuitive and easier to work with > than the branching methods used by Mercurial and Bazaar: > - `git co <branch>` is far more efficient of a workflow than having to > have a separate checkout of every branch I want to work on in a > different top level directory This is misinformation. Neither Mercurial nor Bazaar requires separate checkouts for every branch. > - `git merge|rebase <branch>` and `git cherry-pick <revision>` work > far more easily when all of your branches are kept in the same > repository and top level directory, as compared to the basic equivalents > in Bz/Hg Both Mercurial and Bazaar keep branches in the same repository. And both handle merging as well as Git. And both supports rebase like Git (Mercurial through transplant, Bazaar through the external rebase plugin). What are you really talking about? > b) the index (bad name for what should be called the 'staging area') is > incredibly powerful once you learn how it works and how to make use of it: > - When I start working on multiple things at once, and then decide > that I need to break it up into separate commits or branches, a series > of `git add -p` and `git commit` commands allow me to easily divide all > of my uncommitted changes into a set of distinct patches; then with the > use of `git rebase -i` and `git cherry-pick`, I can reorder those > commits into a more logical order, and then pull specific commits to > other branches as needed Selective commit is a feature of *every* version control system since CVS; some with more, other with less flexibility. It happens that Git gives you a lot of flexibility in this area (even though one of the reasons Linus ditched Monotone was because it allowed cherry-picking... and now Git has the very same feature... what an irony). But this doesn't have anything to do with the index. It seems like you missed the point of the index in your argument. Like you said, it is a "staging area", period. What you do with a single command in all other VCSes, you need more commands (or non-default arguments) with Git because you have this big obstacle in your way. The index helps if your personal workflow is a mess. Otherwise, the index could very well be ditched or disabled by default, and user would use selective commits and stash for that matter, both which make a lot more sense and is easier to understand. The work-commit-work-commit workflow is by far the most common one. It doesn't make much sense to require more commands or non-default arguments to deal with (or bypass) the index in order to support for the most common workflow. > c) more as a personal preference, I find that Git is far more > developer-oriented than Hg/Bz, because it gives you the power and the > flexibility to use Git in a manner that best suits your own style of > development. Everything you pointed above sounds like personal preference. The supposed lack of features you pointed in Mercurial and Bazaar sounded like you never really used them, or at least missed a lot of releases. Being more developer-oriented may be considered another design problem of Git, instead of a feature. Not all projects are composed almost solely of developers, like the Linux kernel. We may have graphics designers, translators, documenters, testers, webmasters, packagers... and users! Mantis itself qualifies. Regards, Juliano. -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead. |
From: John R. <jr...@le...> - 2008-10-30 13:04:42
|
Juliano F. Ravasi wrote: > John Reese wrote: >> a) you have the entire project history on your local machine, which >> means you can do all of the following quickly and without needing to >> talk to a remote, central server (which for SF.net is damn slow): >> - View a log of commits >> - View commit changesets / diffs >> - Create local, versioned testing branches >> - Commit local changes to any branch > > It is important to not confuse concepts of distributed version control > to features that are commonly found in DVCSes. Most of these features, > including local commits are not strictly really tied to the distributed > model. Legend says that Subversion will have local history and local > commits, before becoming a distributed VCS. Yes, but SVN doesn't yet, and I personally hate having to wait for (or even need) slow internet and server connections just to get the history of a file or directory, or view revisions diffs etc. In this case, the fact that existing DVCS tools have the leg up here is exactly why I want to use them. >> c) with cheap, efficient, and easily mergeable branches, we can begin to >> use staging/edge/testing branches for commits, which can then be >> reviewed by others before being merged to master/trunk > > Nothing blocks you from doing this with Subversion, or any other VCS for > that matter. Not as easy at least, sure. Not as easy being the exact point I'm trying to make. >> As to why I feel Git is a better option than others: >> >> a) local, inline branching is more intuitive and easier to work with >> than the branching methods used by Mercurial and Bazaar: >> - `git co <branch>` is far more efficient of a workflow than having to >> have a separate checkout of every branch I want to work on in a >> different top level directory > > This is misinformation. Neither Mercurial nor Bazaar requires separate > checkouts for every branch. They don't require separate checkouts, but their usage of inline branching is not as streamlined or robust feeling as that of Git. This is probably one of the better explanations I've found of why I feel this way: http://www.reddit.com/r/programming/comments/67w6s/use_mercurial_you_git/c03400h >> - `git merge|rebase <branch>` and `git cherry-pick <revision>` work >> far more easily when all of your branches are kept in the same >> repository and top level directory, as compared to the basic equivalents >> in Bz/Hg > > Both Mercurial and Bazaar keep branches in the same repository. And both > handle merging as well as Git. And both supports rebase like Git > (Mercurial through transplant, Bazaar through the external rebase > plugin). What are you really talking about? I'm talking about the fact that *I* think it's much simpler and easier to do in Git over Hg/Bzr, not just in normal usage, but in resolving conflicts, using interactive rebase, etc. And why should I want a DVCS that needs a separate plugin to do it? >> b) the index (bad name for what should be called the 'staging area') is >> incredibly powerful once you learn how it works and how to make use of it: >> - When I start working on multiple things at once, and then decide >> that I need to break it up into separate commits or branches, a series >> of `git add -p` and `git commit` commands allow me to easily divide all >> of my uncommitted changes into a set of distinct patches; then with the >> use of `git rebase -i` and `git cherry-pick`, I can reorder those >> commits into a more logical order, and then pull specific commits to >> other branches as needed > > Selective commit is a feature of *every* version control system since > CVS; some with more, other with less flexibility. It happens that Git > gives you a lot of flexibility in this area (even though one of the > reasons Linus ditched Monotone was because it allowed cherry-picking... > and now Git has the very same feature... what an irony). But this > doesn't have anything to do with the index. > > It seems like you missed the point of the index in your argument. Like > you said, it is a "staging area", period. What you do with a single > command in all other VCSes, you need more commands (or non-default > arguments) with Git because you have this big obstacle in your way. I think you missed *my* point. You start making changes to your files, and then in the middle of your changes, you realize you need to fix or modify something else in the same files you've already edited. So you make your changes. Now, with SVN, you have to commit all that as a single changeset. But with Git's interactive add/commit, you can selectively choose individual changes to files that you want to commit. So you can commit the changes on lines 150-200, but leave the changes on lines 60-90 for a later commit. *That's* the point I'm trying to make where the staging area/index is really starting to shine as a useful tool for manipulating your changes in preparation for commit. > The index helps if your personal workflow is a mess. Otherwise, the > index could very well be ditched or disabled by default, and user would > use selective commits and stash for that matter, both which make a lot > more sense and is easier to understand. Just because I use the index to my advantage doesn't mean my workflow is a mess. You don't need to stoop to personal attacks to get your point across, please. And stash isn't always the best option, although I do like it and it is quite useful. > The work-commit-work-commit workflow is by far the most common one. It > doesn't make much sense to require more commands or non-default > arguments to deal with (or bypass) the index in order to support for the > most common workflow. So if you don't like using the index, just edit your .gitconfig and alias commit to `commit -a` or something. Just because it's the most common workflow doesnt't mean we shouldn't enable those of us who use a more complex one. >> c) more as a personal preference, I find that Git is far more >> developer-oriented than Hg/Bz, because it gives you the power and the >> flexibility to use Git in a manner that best suits your own style of >> development. > > Everything you pointed above sounds like personal preference. The > supposed lack of features you pointed in Mercurial and Bazaar sounded > like you never really used them, or at least missed a lot of releases. Please note that I *did* write above this second list "why I feel Git is better". This is quite obviously me pointing out that this is my opinions and personal preference. And naturally if Git is my favorite, I haven't used Hg or Bzr as extensively or as in depth, but I have used both of them to look at or contribute to different projects. And my *opinion* of them is that they are simpler and easier to grasp than Git, but lack the ability to mold the tools to the developer's habits and best uses. > Being more developer-oriented may be considered another design problem > of Git, instead of a feature. Not all projects are composed almost > solely of developers, like the Linux kernel. We may have graphics > designers, translators, documenters, testers, webmasters, packagers... > and users! Mantis itself qualifies. True, which is once again why I have the *opinion* that Git is better. However, I quote myself again to get my point across: "I personally would rather switch to *any* DVCS tool than stick with using SVN hosted by SourceForge, but I'd also *greatly* prefer that the DVCS choice be Git. "Your mileage may vary; this is just my not-so-humble opinion; question/ignore/flame/berate me as necessary; etc." -- John Reese LeetCode.net |
From: Juliano F. R. <ml...@ju...> - 2008-10-30 19:05:40
|
John Reese wrote: >>> c) with cheap, efficient, and easily mergeable branches, we can begin to >>> use staging/edge/testing branches for commits, which can then be >>> reviewed by others before being merged to master/trunk >> Nothing blocks you from doing this with Subversion, or any other VCS for >> that matter. Not as easy at least, sure. > > Not as easy being the exact point I'm trying to make. The "we can begin to use..." part of your previous message sounded like it would be impossible otherwise. > They don't require separate checkouts, but their usage of inline > branching is not as streamlined or robust feeling as that of Git. This > is probably one of the better explanations I've found of why I feel this > way: > > http://www.reddit.com/r/programming/comments/67w6s/use_mercurial_you_git/c03400h "Robust feeling" is a strange argument. Are we discussing which tool is best suited for the task, or which tool we like it better? Because even nowadays people still like CVS... The whole discussion is pointless if we argue on what we like instead of what is better. And if it is a question of taste, Mercurial offers you bookmarks, that is another way to do branches that is very, very similar to Git's view of branches. > I'm talking about the fact that *I* think it's much simpler and easier > to do in Git over Hg/Bzr, not just in normal usage, but in resolving > conflicts, using interactive rebase, etc. ... > And why should I want a DVCS that needs a separate plugin to do it? And what is the problem with software that is modularly designed? Plugin design is a feature, you don't pay for what you don't need. It allows you to customize your usage of the tool. If I don't like Mercurial's transplant, for example, I can do my own and load it dynamically by adding a line to a config file, without touching the system installation. The Mercurial and Bazaar model allows for you to use only the parts that you need. The KISS principle: less complexity, easier to maintain, more reliable. You may even think about embedding the versioning tool in other software. > I think you missed *my* point. You start making changes to your files, > and then in the middle of your changes, you realize you need to fix or > modify something else in the same files you've already edited. So you > make your changes. > > Now, with SVN, you have to commit all that as a single changeset. Wait... in this point of your message you were talking about how you think Git is better than other DVCSes, now you compare it back to SVN... > But > with Git's interactive add/commit, you can selectively choose individual > changes to files that you want to commit. So you can commit the changes > on lines 150-200, but leave the changes on lines 60-90 for a later > commit. *That's* the point I'm trying to make where the staging > area/index is really starting to shine as a useful tool for manipulating > your changes in preparation for commit. You definitely don't need the index to achieve that. What you described is just interactive commit, or cherry-picking of changes. While in Git you have to use the index and spread it in various interactions before the final commit, in other DVCSes that support interactive commits, you do this all during the single commit phase. If you think it is bad or cumbersome to do all cherry-picking during the commit, you may temporarily store (using cherry-picking) what you don't want to commit, using patch queues or bzr shelve. >> The index helps if your personal workflow is a mess. Otherwise, the >> index could very well be ditched or disabled by default, and user would >> use selective commits and stash for that matter, both which make a lot >> more sense and is easier to understand. > > Just because I use the index to my advantage doesn't mean my workflow is > a mess. You don't need to stoop to personal attacks to get your point > across, please. That "if your personal workflow" in my message was impersonal use of "your" since it follows the conditional "if". So, it was not intended to point at you. Sorry if it looked as a personal attack. My point is that it is generally regarded as a bad programming practice to commit changes without testing. The index allows and incentives exactly that, to commit changes that you are not really sure they are actually correct, since you didn't test what you are committing. In this use-case, specifically, the correct would be to shelve (bzr terminology) the changes you don't want to commit, *test* the application with the selected changes, commit them, than unshelve the remaining changes back. > And stash isn't always the best option, although I do > like it and it is quite useful. Because Git's stash is very poor, compared for example with bzr shelve. In bzr shelve, you "stash" specific files and interactively select specific changes in those files that you want to store away. > True, which is once again why I have the *opinion* that Git is better. > However, I quote myself again to get my point across: Ok. You are fine with your opinion. But then, please, don't say that other DVCSes are worse because they supposedly don't have a specific feature, specially if you cannot attest that as a fact. Note that I didn't say which one is my DVCS of choice until now, except that it clearly isn't Git. That is because it is not my goal to convince people that my DVCS of choice is better, but to instigate investigation about what are the best features each tool has to offer for the project. For that, we use facts, not personal opinion. (I don't intend to sound harsh here, but to move the discussion to more profitable grounds). Best regards, Juliano. -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead. |
From: Juliano F. R. <ml...@ju...> - 2008-10-27 13:28:18
|
Hello Victor, Victor Boctor wrote: > The core dev team has been considering Git for a while now. Several > of the developers have been running a local Git repository that they > use to create their branches and push the changes to the central SVN > using git-svn. We are now considering moving completely to git. The > git repository will be hosted on our server rather than in > Sourceforge. I would like to know if other options, like Mercurial or Bazaar were considered, and why Git was chosen over them. > We would like to open the forum to get feedback on the following: > 1. The idea of moving to Git. Moving to a DVCS: Ok. Moving to Git, specifically: Bad, very bad. > 2. The best way to structure our git repository / repositories, branches, etc. Git (and in fact, most DVCSes) don't offer many options on how you structure your repositories. Every independent module must be stored in its own repository, and nothing else. So, all of mantis source, website, manual, etc... will need to have their own individual repositories. > For contributors / developers using Windows, there is a Git version > for Windows which works fine for interacting with native git, but it > is not as good for git-svn since there are some dependency on svn perl > libraries that don't work well under Windows. Hence, by moving to a > real git repository, such problem should go away. >From my experience, git doesn't "work fine" in Windows... git sucks hard in Windows (based on experience with msysgit 1.5.6.1-preview and 1.6.0.2-preview). Git simply wasn't designed to run in Windows, and the core developers don't even bother with Windows compatibility, leaving to msysgit developers to work hard to "fix" Git in Windows. Also, the lack of an user interface for Windows (a la TortoiseSVN) is another big drawback. Again, Git wasn't designed to be used beyond the command-line and a set of Unix shell scripts, making the task of designing a well-integrated Windows shell extension or IDE plugin a nightmare. > Personally, I'm a Windows user, after a lot of investigations I found > that the following environment that worked best for me: > > 1. Windows Vista with 4 GB You know that this requirement alone is well above like 99% of all computer users, right? > I've found the above setup to be better than cygwin or running ported > applications. I still wonder why people goes through all this hassle to run Git, even experiencing themselves how bad Git is in Windows, instead of using a DVCS that is natively designed to run in Windows. In fact, there is still no match for TortoiseSVN and Subeclipse in terms of feeling that you are actually using a rock-solid well-designed VCS integrated with the shell/IDE. And you can use SVK (a DVCS built on top of Subversion libraries), that works better in Windows and allows you to still use all Subversion goodies, do local commits and work distributed. I find that most people who switched to Git did just because "Linus said so". They in fact never explored the benefits of a DVCS, and were doing just fine with Subversion. GNU Arch, SVK and Monotone were lying around way before Git was developed, there were options available, and nobody cared... There is nothing wrong with going distributed, but I strongly suggest that you consider tools designed to be real DVCSes and to serve a all projects in general, instead of a tool that wasn't initially designed to be used beyond the scope of a single project (the Linux kernel). More in the next message. -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead. |
From: Gianluca S. <gi...@gm...> - 2008-10-27 14:07:39
|
On Mon, Oct 27, 2008 at 2:28 PM, Juliano F. Ravasi <ml...@ju...> wrote: > >> For contributors / developers using Windows, there is a Git version >> for Windows which works fine for interacting with native git, but it >> is not as good for git-svn since there are some dependency on svn perl >> libraries that don't work well under Windows. Hence, by moving to a >> real git repository, such problem should go away. > > >From my experience, git doesn't "work fine" in Windows... git sucks hard > in Windows (based on experience with msysgit 1.5.6.1-preview and > 1.6.0.2-preview). Git simply wasn't designed to run in Windows, Very true, I bet Linus was not thinking about that use case... Of course that doesn't mean it can't be ported, and the msysgit project is proving that. > and the > core developers don't even bother with Windows compatibility, Yeah, why should they, given that it was created to support the Linux kernel development? > leaving to > msysgit developers to work hard to "fix" Git in Windows. and I think they deserve all the respect for accomplishing what they've done. > > Also, the lack of an user interface for Windows (a la TortoiseSVN) is > another big drawback. Again, Git wasn't designed to be used beyond the > command-line and a set of Unix shell scripts, making the task of > designing a well-integrated Windows shell extension or IDE plugin a > nightmare. This is FUD. > >> Personally, I'm a Windows user, after a lot of investigations I found >> that the following environment that worked best for me: >> >> 1. Windows Vista with 4 GB > > You know that this requirement alone is well above like 99% of all > computer users, right? I agree with you here, albeit for a different reason. We need more regular contributors; if we start by suggesting you need to install a Virtual machine with Linux just to download sources I guess we're automatically loosing most (if not all) the Windows contributors... -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: Juliano F. R. <ml...@ju...> - 2008-10-27 16:24:01
|
Gianluca Sforna wrote: > Yeah, why should they, given that it was created to support the Linux > kernel development? You hit the point! Here is where Git contradicts itself. If Git was created to support the Linux kernel development, why people use it to manage other projects? If you are going to think that Git shouldn't bother with Windows support (that is the platform of most developers), then you may also agree that Git is a Linux-specific tool that was not intended to be used outside Linux kernel development, right? (This is a rhetorical question, of course it is not). This is not how open-source works. Look, for example, Subversion, Bazaar and Mercurial. New releases are new releases for all supported platforms. I have Svn 1.5.4 here on my Linux box, while at the same time the rest of my team all have Svn 1.5.4 on their Windows and Mac boxes too. Client and server. With Git, new releases are done without the participation of the msysgit developers, because that would "hinder" Git development. They have to play catch up game after every Git release, because git and msysgit are different repositories, different projects, different people. If I switch to a shining new version of Git that makes backwards-incompatible changes to the repository or the protocol, all the Windows developers are hindered, because they don't have a new version until msysgit catch up. That is why it is important to think of the project as a whole. Please don't nail down your project with thoughts like "why would they, given that it was created to support [a single project or goal that doesn't include all your potential users]". The book "Producing Open Source Software", by Karl Fogel (who also happens to be a Subversion developer), available from O'Relly and online at http://producingoss.com/ is a very good reading. >> Also, the lack of an user interface for Windows (a la TortoiseSVN) is >> another big drawback. Again, Git wasn't designed to be used beyond the >> command-line and a set of Unix shell scripts, making the task of >> designing a well-integrated Windows shell extension or IDE plugin a >> nightmare. > > This is FUD. I made three points in this paragraph, you accuse me of FUD, and don't say what you think is FUD. I'll assume that you agree that the lack of a Windows UI being a drawback and that Git wasn't designed (well, initially) to be used beyond a command-line tool; leaving the debatable point of it being a nightmare to develop a well-integrated Windows shell extension. This revolves a lot of history of discussions about Git design, that is way off-topic in this list. I'll summarize the best as I can. In order to integrate well with Windows, Git needs to have a modular, library-oriented design. But since the beginning Git was a monolithic binary that did everything (it is still today). The first problem is the lack of a library design: make the user interaction and core repository handling code decoupled, no, I mean, *really* decoupled. This was not considered from the beginning, and Git grew to the size that this is extremely difficult to do now (specially API stabilization), it would require a lot of work, and would result into a large patch with very low probability of being reviewed and merged into the core Git. It would shake the grounds where Git was built upon and, well, it would make Git a little slower on Linux (and way faster in Windows). They managed to create a libgit.a static library, but doesn't help much, since the API is not really stable, and you can't load a static library into a running executable. In order to integrate with Windows Explorer, you need the version control running in as a runtime-loadable shared library, this shared library must have everything that is needed to handle the repository, or link to other complementary shared libraries. If you can't git itself into this shared library, the only other option would be to call it externally, for everything it needs to do. This carries a lot of problems, first because CreateProcess() in Windows is extremely expensive, second because sending and receiving from stdin/stdout of a child process causes a lot of other issues, and breaks easily. Parts of Git (like git-svn) are perl or bash scripts, what means also loading interpreters to run and extract results from Git (and there is little willing to port these pieces to native code by their original developers). > I agree with you here, albeit for a different reason. > > We need more regular contributors; if we start by suggesting you need > to install a Virtual machine with Linux just to download sources I > guess we're automatically loosing most (if not all) the Windows > contributors... Then we agree for the same reason! That is why I said that "Windows Vista with 4GB" is way too much of a requirement. We really don't want to lose contributors by placing too many obstacles for them to contribute. -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead. |
From: Gianluca S. <gi...@gm...> - 2008-10-27 13:51:11
|
On Mon, Oct 27, 2008 at 8:21 AM, Victor Boctor <vb...@gm...> wrote: > The core dev team has been considering Git for a while now. Several > of the developers have been running a local Git repository that they > use to create their branches and push the changes to the central SVN > using git-svn. We are now considering moving completely to git. The > git repository will be hosted on our server rather than in > Sourceforge. I liked git very much despite using probably 1% of its features but, TBH, I fail to see why we should drop the idea that the sourceforge SVN repo is the authoritative storage for sources. git.m.o can still exist and host all the branches we like it to serve. When something is ready, pushing the relevant bits on SVN should be fairly easy. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: Robert M. <rob...@gm...> - 2008-10-27 23:08:53
|
2008/10/27 Victor Boctor <vb...@gm...>: > We would like to open the forum to get feedback on the following: > 1. The idea of moving to Git. I for one would enjoy the move to git, since it makes it much easier to track development than SVN. Since the trend is moving towards an even more open development process I'd also like to see a two-liner about how/when patches are accepted ( I think it's clear enough why _not_ ). I know about http://www.mantisbt.org/general_development.php#patches and http://www.mantisbt.org/guidelines.php , but it's not quite what I was looking for. Perhaps even some clarification in regard to what the preferred way of getting patches applied is: a) attach patch to bug report b) attach patch to bug report + mail mantisbt-dev c) git format-patch && git send-email d) git pull 'request' > 2. The best way to structure our git repository / repositories, branches, etc. I've tracked the changes on github for a while and I'm also tracking the repo on mantisforge. I think the current branches/tags are fine, nothing to be changed. Would you consider also hosting git repositories for users? Robert |
From: Glenn H. <thr...@lo...> - 2008-10-28 18:47:18
|
On 27-Oct-08, at 3:21 AM, Victor Boctor wrote: > Hi all, > > The core dev team has been considering Git for a while now. Several > of the developers have been running a local Git repository that they > use to create their branches and push the changes to the central SVN > using git-svn. We are now considering moving completely to git. The > git repository will be hosted on our server rather than in > Sourceforge. > > We are considering several ways of setting up our git repository(ies) > and how we support the following: > > 1. Ability for developers to check-in to their branch/repository so > that the code is available for others to pull / code review. > 2. Ability for developers to pull patches from contributors. > 3. Ability for multiple developers to work together on a feature and > pull from each other. > 4. Ability for the community to pull features from each other or from > developer branches. > 5. Implement a build process which gets the latest code on the > supported branches and packages downloadable daily releases (assuming > there is at least 1 check-in). > > We would like to open the forum to get feedback on the following: > 1. The idea of moving to Git. > 2. The best way to structure our git repository / repositories, > branches, etc. While not being a git fan (yet), I do agree that moving forward we need some changes. One of the problems we are facing at this time (and in past) is selective propagation of changes to older releases. We have two (soon to be three) active branches that all need maintaining. We also need to do more sharing of code for testing before release so that we can ensure that the HEAD of each branch is stable. From the discussion, it looks like we have two camps, active developers, and generally, read only users of the HEAD of each stream. The latter might include casual developers, or testers. A switch to git would definitely help the mainstream developers, but would probably adversely affect the more casual users. I would suspect that a 'nightly build' would satisfy most of the requirements for casual users in that they are traceable to the main branches in the developer repository. Further, if done properly, patches against a nightly build can be easily integrated into the main stream using the merge features of the tools. Would this be the correct solution for both classes of users? ... Glenn -- Glenn Henshaw Logical Outcome Ltd. e: thr...@lo... w: www.logicaloutcome.ca Mantis Developer and User |
From: John R. <jr...@le...> - 2008-10-30 19:28:28
|
The discussion is likely not getting anywhere, so I will just sum up what I was trying to accomplish: 1. Discuss why we as the development team want to move away from SVN to a DVCS tool, so that we can implement certain development practices more easily than we can using SVN, or similarly, SVN hosted by SourceForge. 2. Discuss why we wanted to move to Git as opposed to other DVCS tools like Mercurial or Bazaar. This is more of a personal preference choice, as most of us were trying to establish that most DVCS tools can accomplish the same tasks; it's merely a choice of preference as to which you choose. Our (or rather, Victor, Giallu, my) preference is currently on Git. Unfortunately, like the venerable Emacs/Vim topic, DVCS choices tend to result in 'holy wars' type of discussions, in which each side feels that their choice is the best choice, and unfortunately, neither side is likely to ever be capable of changing their preference. I don't think there are really any 'facts' that would really have any bearing on which DVCS we choose, because all the major DVCS tools have the same overall feature sets, and anyone can easily pick up any DVCS tool and start using it, assuming the person in question is willing to learn and read documentation; if not, all hope is lost anyways. The distinguishing factors are therefore the implementation details and which of the tools implement the details in a manner favorable to the developers. Disagree? -- John Reese LeetCode.net |
From: Victor B. <vb...@gm...> - 2008-10-30 19:55:28
|
Just adding some more notes: 1. It seems that as a development team, we would want to move to *any* DVCS. Is there a value in keeping the Sourceforge SVN repository up to date? i.e. on commit push the data to Sourceforge? Would patches submitted by contributors based on SVN or our new DVCS both work when applying the changes to DVCS? (assuming no code conflicts of course). This model may apply contributors to continue to use SVN or a nightly build. 2. For the Windows environment, I had the following experience: a. The Windows port of git works fine against a native git repository. b. The git-svn is only available for cygwin and is hard to setup right / potentially broken. c. Virtual Machine option is a nice to have, it is not a requirements. 3. Some Windows/DVCS related questions: 1. Did any one use any of the DVCS products under Windows? Specially in combination with TortoiseXX interface? 2. If so which ones and what is your experience? 3. Is it possible to run this DVCS with SVN as the backend? i.e. same way we did with Git. I think it may be feasible to test one of the other options with Windows / Linux and compare with Git. However, I don't think it is efficient to test everyone out there. On Thu, Oct 30, 2008 at 12:28 PM, John Reese <jr...@le...> wrote: > The discussion is likely not getting anywhere, so I will just sum up > what I was trying to accomplish: > > 1. Discuss why we as the development team want to move away from SVN to > a DVCS tool, so that we can implement certain development practices more > easily than we can using SVN, or similarly, SVN hosted by SourceForge. > > 2. Discuss why we wanted to move to Git as opposed to other DVCS tools > like Mercurial or Bazaar. This is more of a personal preference choice, > as most of us were trying to establish that most DVCS tools can > accomplish the same tasks; it's merely a choice of preference as to > which you choose. Our (or rather, Victor, Giallu, my) preference is > currently on Git. > > > Unfortunately, like the venerable Emacs/Vim topic, DVCS choices tend to > result in 'holy wars' type of discussions, in which each side feels that > their choice is the best choice, and unfortunately, neither side is > likely to ever be capable of changing their preference. > > I don't think there are really any 'facts' that would really have any > bearing on which DVCS we choose, because all the major DVCS tools have > the same overall feature sets, and anyone can easily pick up any DVCS > tool and start using it, assuming the person in question is willing to > learn and read documentation; if not, all hope is lost anyways. > > The distinguishing factors are therefore the implementation details and > which of the tools implement the details in a manner favorable to the > developers. > > Disagree? > > -- > John Reese > LeetCode.net > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Victor B. <vb...@gm...> - 2008-11-04 19:57:32
|
Hi all, I would like to thank everyone who has contributed to this discussion, it has been very useful to us and has helped us to drill further to make the decision. It also helped us understand the concerns of the community and make sure we address them in our new platform. Based on that, following is the summary of our decision: 1. Based on this discussion we have re-considered git, hg and bazaar. hg / git were the stronger candidates. However, we decided on git for the following reasons: a. We have already built integration plugin between Mantis and git. b. The current devs have already been experimenting with git for a while. c. Native git works fine on Windows (msysgit) and fixes have been merged back in main code base. 2. For users, we will provide a way for them to download nightly builds without having to use any source control tool. 3. For contributors not familiar with git, they can provide diffs against nightly builds. 4. For translators, they will use a translation infrastructure. Siebrand is currently co-ordinating this via some translation wiki infrastructure which seems to be effective in keeping our translation updated and adding new languages. 5. There will be follow up email threads relating to our revised work flows based on the fact that we will be using a DVCS which allows us to enhance our process. 6. As of now, there is a commit freeze to SVN since we are in the process of migration to git. On Thu, Oct 30, 2008 at 11:55 AM, Victor Boctor <vb...@gm...> wrote: > Just adding some more notes: > > 1. It seems that as a development team, we would want to move to *any* > DVCS. Is there a value in keeping the Sourceforge SVN repository up > to date? i.e. on commit push the data to Sourceforge? Would patches > submitted by contributors based on SVN or our new DVCS both work when > applying the changes to DVCS? (assuming no code conflicts of course). > > This model may apply contributors to continue to use SVN or a nightly build. > > 2. For the Windows environment, I had the following experience: > a. The Windows port of git works fine against a native git repository. > b. The git-svn is only available for cygwin and is hard to setup right > / potentially broken. > c. Virtual Machine option is a nice to have, it is not a requirements. > > 3. Some Windows/DVCS related questions: > 1. Did any one use any of the DVCS products under Windows? Specially > in combination with TortoiseXX interface? > 2. If so which ones and what is your experience? > 3. Is it possible to run this DVCS with SVN as the backend? i.e. same > way we did with Git. > > I think it may be feasible to test one of the other options with > Windows / Linux and compare with Git. However, I don't think it is > efficient to test everyone out there. > > On Thu, Oct 30, 2008 at 12:28 PM, John Reese <jr...@le...> wrote: >> The discussion is likely not getting anywhere, so I will just sum up >> what I was trying to accomplish: >> >> 1. Discuss why we as the development team want to move away from SVN to >> a DVCS tool, so that we can implement certain development practices more >> easily than we can using SVN, or similarly, SVN hosted by SourceForge. >> >> 2. Discuss why we wanted to move to Git as opposed to other DVCS tools >> like Mercurial or Bazaar. This is more of a personal preference choice, >> as most of us were trying to establish that most DVCS tools can >> accomplish the same tasks; it's merely a choice of preference as to >> which you choose. Our (or rather, Victor, Giallu, my) preference is >> currently on Git. >> >> >> Unfortunately, like the venerable Emacs/Vim topic, DVCS choices tend to >> result in 'holy wars' type of discussions, in which each side feels that >> their choice is the best choice, and unfortunately, neither side is >> likely to ever be capable of changing their preference. >> >> I don't think there are really any 'facts' that would really have any >> bearing on which DVCS we choose, because all the major DVCS tools have >> the same overall feature sets, and anyone can easily pick up any DVCS >> tool and start using it, assuming the person in question is willing to >> learn and read documentation; if not, all hope is lost anyways. >> >> The distinguishing factors are therefore the implementation details and >> which of the tools implement the details in a manner favorable to the >> developers. >> >> Disagree? >> >> -- >> John Reese >> LeetCode.net >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |