Re: Proposed git migration plan
Hi Barry, thanks for your work! On Mon, Aug 25, 2014 at 10:00 PM, Barry Warsaw wrote: > Here's the page I mentioned regarding a *proposed* transition plan to using > git for team packages. It's more or less a brain dump right now, and don't > feel like you need to read it before the DC14 session. > > https://wiki.debian.org/Python/GitPackaging nothing against your effort or experiments (I really appreciate it), but I still don't see what is the advantages of moving to Git. It seems to me like very vocal Git fanatics, who refuse to touch any package which is not maintained in Git (-.-), are pushing and pushing to that VCS without any clear advantage. Upstream releases history? why do we need to care, we are packagers we should care about packaging commits history. ultimately, you'll always have to deal with tarballs, so we need a tool to import released tarballs in a VCS and then another tool to re-generate the tarball from the VCS again? seems kinda twisted to me :) And no, not the whole programming world is using Git for upstream code (sometimes we're not even able to teach upstream to use proper versions), so the usual mantra "I can pull from upstream repo and be happy ever after" is kinda weak. Offline commits? how many time (for real..) you badly needed it? i guess so few that if you (for one time) just do a big commit instead of a storm of micro commit the world wont stop is there anything else so "attractive" about git? If we don't define *upfront* what are the problems we currently have and that we want to solve, then we're just proposing a technical exercise without a real gain. and I cant stress this point never enough. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAB4XWXzM8nDbwLBnTMbjTc_T+MMqWWQiQjDKeS0R=yjhh6y...@mail.gmail.com
Re: Proposed git migration plan
Hi Sandro, On Wed, 27 Aug 2014, Sandro Tosi wrote: > It seems to me like very vocal Git fanatics, who refuse to touch any > package which is not maintained in Git (-.-), are pushing and pushing > to that VCS without any clear advantage. You might dismiss those people but you're speaking of true contributors that you're aleniating here. If we really want to stay an all-inclusive team we should use what the majority of (possible) contribtuors prefer to use. python-modules is about the only team I'm part of that is not yet using git. It's an annoyance to have to continue to use svn-buildpackage when I only use git everywhere else. > Upstream releases history? why do we need to care, we are packagers we > should care about packaging commits history. Because your packaging decisions are not influenced by upstream changes? > from the VCS again? seems kinda twisted to me :) And no, not the whole > programming world is using Git for upstream code (sometimes we're not > even able to teach upstream to use proper versions), so the usual > mantra "I can pull from upstream repo and be happy ever after" is > kinda weak. Not everybody is using git but I think that you should face it, most of the upstreams projects do. > is there anything else so "attractive" about git? It's 200% more easy to manage multiple branches and merge them properly. Most of the average python modules will not need multiple branches but for things like python-django, we do need multiple branches... and the fact that svn is such a pain means that the security updates were not managed in svn for example... And handling security updates in svn is a pain because you can't commit localy and push only when the security update is disclosed publicly. etc. All those are real problems for real people doing packaging work. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827084040.gc23...@x230-buxy.home.ouaza.com
Re: Proposed git migration plan
Le 26/08/2014 20:36, Hans-Christoph Steiner a écrit : > * the git-buildpackage workflow is really quite wonderful and reasonably > flexible, I highly recommend it, and I think it will improve the productivity > of this team. Hello, At Wikimedia we solely use git-buildpackage. DD Michael Prokop wrote a set of script that let you easily build the package using Jenkins which can be made to poll the git repo, and hence build your package when a commit is pushed: http://jenkins-debian-glue.org/ Coupled with a pre review software such as Gerrit, that let one propose a patchset, have the build result displayed and iterate until the patch is ready to land in the branch. That is a huge time saver for us. -- Antoine "hashar" Musso -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fd9713.8050...@free.fr
Re: DebConf14 svn->git migration BOF notes
On Wed, 27 Aug 2014, Stuart Prescott wrote: > > I've done some personal investigation since the BOF, and am preparing > > some really simple migration scripts, so we can get a feel for what it > > will look like. My scripts so far (very very simple) > > git://git.debian.org/users/stefanor/dpmt-migration.git > > is there any reason to use a loop around git-import-dsc rather than git- > import-dscs --debsnap here? I haven't looked at stefano's script but git-import-dscs will import all source packages in a single linear history (importing the packages by increasing version) and that isn't representative of the true history. For python-django, I imported all the "normal" versions in the debian/sid branch but manually imported the "+deb7uX" in a debian/wheezy branch, the "+squeezeX" in a debian/squeeze branch, etc. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827085224.gd23...@x230-buxy.home.ouaza.com
Re: Proposed git migration plan
Le 27/08/2014 10:13, Sandro Tosi a écrit : > Offline commits? how many time (for real..) you badly needed it? i > guess so few that if you (for one time) just do a big commit instead > of a storm of micro commit the world wont stop As a side effect, that also mean you don't have to use a potentially lagged network connection when doing simple operations. There is nothing I hate more than waiting for network when using the commands log, commit or blame. > is there anything else so "attractive" about git? Cheap local branches which let you pill up work in progress patches / rewrite without having to keep several copy of the same svn repo. The branches in git are just a name pointing to a commit in the tree. The stash, which let you save your uncommited changes and come back to them later (think of it as lightweight branches). That is really nice when you have to interrupt your workflow, stash it, handle the interrupt, reapply your stash and resume work. Tags can be signed with gpg. They are a pointer to a commit just like branches, and hence don't force you to do a full copy to create a tag. Switching between branches is a breeze and does not need network access either. > If we don't define *upfront* what are the problems we currently have > and that we want to solve, then we're just proposing a technical > exercise without a real gain. and I cant stress this point never > enough. I agree there, would be nice to list the problems with svn. But I guess most of them are related to svn being a bad (and slow) CSV system. -- Antoine "hashar" Musso -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fd99c2.5040...@free.fr
Re: Proposed git migration plan
Le 25/08/2014 23:00, Barry Warsaw a écrit : > Here's the page I mentioned regarding a *proposed* transition plan to using > git for team packages. It's more or less a brain dump right now, and don't > feel like you need to read it before the DC14 session. > > https://wiki.debian.org/Python/GitPackaging > > Food for thought and discussion. >From another reply: have you guys considered using a pre commit workflow review system ? In such a system developers propose their change in a gate and they are reviewed/approved before landing in the branch. That let anyone propose a change without potentially breaking the master branch used to build package from. The well known example are GitHub pull requests. OpenStack and Wikimedia foundations are using Gerrit. It is an open source java application developed by Google to develop the Android SDK. It is interface is not the best, but it handles that pre commit review workflow very well. -- Antoine "hashar" Musso -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fd9a95.7090...@free.fr
Re: Proposed git migration plan
On Wed, Aug 27, 2014 at 9:40 AM, Raphael Hertzog wrote: > Hi Sandro, > > On Wed, 27 Aug 2014, Sandro Tosi wrote: >> It seems to me like very vocal Git fanatics, who refuse to touch any >> package which is not maintained in Git (-.-), are pushing and pushing >> to that VCS without any clear advantage. > > You might dismiss those people but you're speaking of true contributors > that you're aleniating here. If we really want to stay an all-inclusive > team we should use what the majority of (possible) contribtuors prefer > to use. like true contributors are those using svn right now. and what about the majority of contributors now? we should change just because maybe, eventually, if we're lucky we'll attract more contributors? saying "I won't contribute to your team if you don't move to Git" is IMHO arrogance and against team work (but we know. I'm different :) ) > python-modules is about the only team I'm part of that is not yet using > git. It's an annoyance to have to continue to use svn-buildpackage when > I only use git everywhere else. ditto in my first message :) >> Upstream releases history? why do we need to care, we are packagers we >> should care about packaging commits history. > > Because your packaging decisions are not influenced by upstream changes? i don't follow? is that an advantage of having the upstream source code in the Debian packaging repository? >> from the VCS again? seems kinda twisted to me :) And no, not the whole >> programming world is using Git for upstream code (sometimes we're not >> even able to teach upstream to use proper versions), so the usual >> mantra "I can pull from upstream repo and be happy ever after" is >> kinda weak. > > Not everybody is using git but I think that you should face it, most > of the upstreams projects do. i dont think so. It might be true for the big projects, but look at the vast majority of the packages in DMPT/PAPT, they are small modules/apps how many of them are using git? I wont say "most" more "few" of them. >> is there anything else so "attractive" about git? > > It's 200% more easy to manage multiple branches and merge them properly. > Most of the average python modules will not need multiple branches but for > things like python-django, we do need multiple branches... and the fact > that svn is such a pain means that the security updates were not managed > in svn for example... branches exist in svn too (I admin they are harderd than git tho) and security updates always evolve in 2 separate ways than current development (in fact, I think you're referring to update in stable, so you'll have a branch for stable and trunk, which likely are at 2 different versions, evolving indipendently. I did that for matplotlib, and it's doable) > And handling security updates in svn is a pain because you can't commit > localy and push only when the security update is disclosed publicly. that's true indeed. > etc. > > All those are real problems for real people doing packaging work. you skipped the part of what are the problems the teams is facing with svn we want to solve with git, while it seems you're talking about your experience with Django alone, which is important of course but not necessarily representative of a huge amount of packages in our teams. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxxkqjpqxbxhv1kzd8ule-n2zjwczi3r7fc_hj08ueu...@mail.gmail.com
Re: Proposed git migration plan
On Wed, Aug 27, 2014 at 9:41 AM, Antoine Musso wrote: > Le 27/08/2014 10:13, Sandro Tosi a écrit : > >> Offline commits? how many time (for real..) you badly needed it? i >> guess so few that if you (for one time) just do a big commit instead >> of a storm of micro commit the world wont stop > > As a side effect, that also mean you don't have to use a potentially > lagged network connection when doing simple operations. There is > nothing I hate more than waiting for network when using the commands > log, commit or blame. I rarely need to use log, and I used to work on the svn repo on a 56k lines no later than 2 years ago, so I know what means a slow network. Still I was able to do quite a lot of work. would it be possible having the whole history of packages in git? i highly doubt so :) >> is there anything else so "attractive" about git? > > Cheap local branches which let you pill up work in progress patches / > rewrite without having to keep several copy of the same svn repo. The > branches in git are just a name pointing to a commit in the tree. > > The stash, which let you save your uncommited changes and come back to > them later (think of it as lightweight branches). That is really nice > when you have to interrupt your workflow, stash it, handle the > interrupt, reapply your stash and resume work. > > Tags can be signed with gpg. They are a pointer to a commit just like > branches, and hence don't force you to do a full copy to create a tag. > > Switching between branches is a breeze and does not need network access > either. I was referring to attractive features of git in regarding to Debian packaging >> If we don't define *upfront* what are the problems we currently have >> and that we want to solve, then we're just proposing a technical >> exercise without a real gain. and I cant stress this point never >> enough. > > I agree there, would be nice to list the problems with svn. But I guess > most of them are related to svn being a bad (and slow) CSV system. well, let's first see the list of problems/features we have/want and then let's talk later of the solutions to them, not the other way around Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAB4XWXy3gJfOMAdys=LjXPK=rtjdv1ux-lfg3fmdkbyiin6...@mail.gmail.com
Re: Proposed git migration plan
On Wed, 27 Aug 2014, Sandro Tosi wrote: > like true contributors are those using svn right now. and what about > the majority of contributors now? we should change just because maybe, > eventually, if we're lucky we'll attract more contributors? saying "I > won't contribute to your team if you don't move to Git" is IMHO > arrogance and against team work (but we know. I'm different :) ) Please don't try to split contributors in two camps. I do continue to use svn-buildpackage for the few django extensions that I maintain in python-modules. And even if I moved python-django to git, I'm still a team contributor even if I touch only a small subset of packages. > > Because your packaging decisions are not influenced by upstream changes? > > i don't follow? is that an advantage of having the upstream source > code in the Debian packaging repository? Yes, I regularly use "git log" on upstream metadata files to see whether we missed some new (optional) dependencies and stuff like that. > > Not everybody is using git but I think that you should face it, most > > of the upstreams projects do. > > i dont think so. It might be true for the big projects, but look at > the vast majority of the packages in DMPT/PAPT, they are small > modules/apps how many of them are using git? I wont say "most" more > "few" of them. No point in arguing here (I don't have time to do a proper analysis and come up with figures). That said in my experience, most new stuff I tend to package are actually maintained in github or a similar service. The fact that we are grabbing .tar.gz on pypi means that we might also not be directly aware that the tarball is generated out of a git repository. > > It's 200% more easy to manage multiple branches and merge them properly. > > Most of the average python modules will not need multiple branches but for > > things like python-django, we do need multiple branches... and the fact > > that svn is such a pain means that the security updates were not managed > > in svn for example... > > branches exist in svn too (I admin they are harderd than git tho) and > security updates always evolve in 2 separate ways than current > development (in fact, I think you're referring to update in stable, so > you'll have a branch for stable and trunk, which likely are at 2 > different versions, evolving indipendently. I did that for matplotlib, > and it's doable) I said "200% more easy", I know that they are doable, but it's just painful... > > All those are real problems for real people doing packaging work. > > you skipped the part of what are the problems the teams is facing with > svn we want to solve with git, while it seems you're talking about > your experience with Django alone, which is important of course but > not necessarily representative of a huge amount of packages in our > teams. And? If we want a single VCS then we must cater to the most demanding use cases. Obviously svn-buildpackage is just fine for small packages with a single branch and no patches... Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827091911.ge23...@x230-buxy.home.ouaza.com
Re: Proposed git migration plan
On 2014-08-27 at 10:40:40 +0200, Raphael Hertzog wrote: > On Wed, 27 Aug 2014, Sandro Tosi wrote: > > It seems to me like very vocal Git fanatics, who refuse to touch any > > package which is not maintained in Git (-.-), are pushing and pushing > > to that VCS without any clear advantage. > You might dismiss those people but you're speaking of true contributors > that you're aleniating here. If we really want to stay an all-inclusive > team we should use what the majority of (possible) contribtuors prefer > to use. > > python-modules is about the only team I'm part of that is not yet using > git. It's an annoyance to have to continue to use svn-buildpackage when > I only use git everywhere else. This is expecially true for *new* contributors, who are more likely to be used to the git workflow and in a situation where they have to learn new skills (svn and svn packaging) that are only used in this team (or just do their packaging elsewhere). -- Elena ``of Valhalla'' -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827091901.gb6...@virginsteele.home.trueelena.org
Re: Proposed git migration plan
Hi Sandro, > I rarely need to use log, and I used to work on the svn repo on a 56k [..] that you rarely use log is (a) not relevant to the people who would use it and (b) quite possibly highly influenced by the fact that svn log is so slow and painful. Remember that the tool can shape the user. >> Cheap local branches which let you pill up work in progress patches / >> rewrite without having to keep several copy of the same svn repo. The >> branches in git are just a name pointing to a commit in the tree. >> >> The stash, which let you save your uncommited changes and come back to >> them later (think of it as lightweight branches). That is really nice >> when you have to interrupt your workflow, stash it, handle the >> interrupt, reapply your stash and resume work. >> >> Tags can be signed with gpg. They are a pointer to a commit just like >> branches, and hence don't force you to do a full copy to create a tag. >> >> Switching between branches is a breeze and does not need network access >> either. > > I was referring to attractive features of git in regarding to Debian > packaging these *are* things that are attractive for packaging work. * I use branches extensively when experimenting with changes to packaging. What gets pushed might not look like that was what happened, but the branch was there along the way. * I use stash quite a lot to be able to better articulate the work I'm doing in commits and as testing smaller changes. I even used it the other day in my little case story on git-buildpackage. * (signed tags are probably an inherently good thing, but are really only nice to have for us at this stage) * Because I use branches a lot, I switch between them, rebase work and merge it quite a lot. > well, let's first see the list of problems/features we have/want and > then let's talk later of the solutions to them, not the other way > around This discussion has been had many times before over many years. Of late, the difficulty in switching VCS has been the blocker. I don't think there are many people who are unconvinced that switching makes sense from a technical or workflow perspective. I also don't think there are many people who are interested in rehashing the entire discussion yet again. It's almost as boring as systemd discussions. Fundamentally, one of the problems is svn. Even if you don't want the thigns git offers, just use git as a new version of svn spelt differently, then you'll still be able to work effectively on packages and you only have two new commands you need to use (assuming you aren't already using debcheckout and debcommit, of course). Subversion lacks features that make packaging work much easier to do. The tools shape what you do -- you said that you don't use branches or log much and that's going to be partly because they are so crap in svn. In the past, I didn't use these features either when I was only using svn. Now I know they are useful things, I use them quite a lot because they are so easy and efficient in git. When I go back to working on svn projects, I realise how much the tool is deficient and how much the deficiencies of the tool lead to deficiencies in process. Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ltkaj1$gs8$1...@ger.gmane.org
Re: Proposed git migration plan
> This discussion has been had many times before over many years. Of late, the and it was never driven by the problems we have, but just by "oh look how cool git is", "everybody else is using it, and i'm too lazy to learn a new tool" arguments. > difficulty in switching VCS has been the blocker. I don't think there are > many people who are unconvinced that switching makes sense from a technical > or workflow perspective. I also don't think there are many people who are > interested in rehashing the entire discussion yet again. It's almost as > boring as systemd discussions. sure, do as you want, git is a great DVCS, and all the other teams are using it > Subversion lacks features that make packaging work much easier to do. The > tools shape what you do -- you said that you don't use branches or log much > and that's going to be partly because they are so crap in svn. In the past, OTOH don't assume I never used git for packaging; even in that case I rarely *need* to use log; regarding branching it might be useful for huge changes (even if I consider it only useful when developing, not packaging) but the majority - come on - of those dont require branching (or do you branch to change Standard-Versions, or to update debian/watch?). turning down my arguments because "your wf is flawed because you use crappy tool" is kinda weak but I'll accept it. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxyatibd22rs7j-7pdebjbzjn6z+cazzskua538yrix...@mail.gmail.com
Re: Proposed git migration plan
On Aug 27, 2014, at 10:30 AM, Antoine Musso wrote: >Coupled with a pre review software such as Gerrit, that let one propose >a patchset, have the build result displayed and iterate until the patch >is ready to land in the branch. I personally love such gated systems when working on software. They might also be a good value for packaging work, if they can do things like run lintian and DEP-8 tests too. Sometimes it's necessary to bypass such gates, e.g. security releases. Once we're converted to git, exploring these other options would be nice, IMHO. One thing at a time though. :) -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827075445.4424d6c4@anarchist
Re: Proposed git migration plan
On 2014-08-27 01:41, Antoine Musso wrote: > Le 27/08/2014 10:13, Sandro Tosi a écrit : > >> Offline commits? how many time (for real..) you badly needed it? i >> guess so few that if you (for one time) just do a big commit instead >> of a storm of micro commit the world wont stop > > As a side effect, that also mean you don't have to use a potentially > lagged network connection when doing simple operations. There is > nothing I hate more than waiting for network when using the commands > log, commit or blame. This annoys me to no end as well. >> is there anything else so "attractive" about git? > > Cheap local branches which let you pill up work in progress patches / > rewrite without having to keep several copy of the same svn repo. The > branches in git are just a name pointing to a commit in the tree. I would really like to emphasize this one. The ability to work locally, then rewrite that work, and only *then* publish it is invaluable to me. When implementing a feature, I don't need to share the history of all mistakes I made with the world, because to everyone else but me, those are just noise polluting the history and unnecessarily complicating it. Instead, I implement the feature locally, and when it works as intended, I rewrite the entire history so that it is clean and comprehended, and only *then* do I push. > The stash, which let you save your uncommited changes and come back to > them later (think of it as lightweight branches). That is really nice > when you have to interrupt your workflow, stash it, handle the > interrupt, reapply your stash and resume work. > > Tags can be signed with gpg. They are a pointer to a commit just like > branches, and hence don't force you to do a full copy to create a tag. > > Switching between branches is a breeze and does not need network access > either. > >> If we don't define *upfront* what are the problems we currently have >> and that we want to solve, then we're just proposing a technical >> exercise without a real gain. and I cant stress this point never >> enough. > > I agree there, would be nice to list the problems with svn. But I guess > most of them are related to svn being a bad (and slow) CSV system. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fdfb50.3000...@kvr.at
Re: Proposed git migration plan
Hi Sandro, On Aug 27, 2014, at 09:13 AM, Sandro Tosi wrote: >nothing against your effort or experiments (I really appreciate it), >but I still don't see what is the advantages of moving to Git. There's "moving to git" and "moving to a dvcs" - slightly different, but related issues. For me, moving to a true dvcs has overwhelming benefits, some of which aren't clear until you've immersed yourself in the dvcs world. Cheap branches, off-line work (e.g., Debconf attendance sometimes involves long airplane rides :), the ability to push branches for easy review, mentorship, sponsorship by others (a *huge* win IMHO). svn just makes so many of those things too painful that we don't do them. git would not have been my top choice for a dvcs, but let's face it, it's won. As sad as it is for me personally, network effects win, and adopting the most popular of the current crop of dvcses will attract (or at least not repel ;) new contributors to the team. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827083845.775a631d@anarchist
Re: Proposed git migration plan
On 27 August 2014 18:13, Sandro Tosi wrote: > > is there anything else so "attractive" about git? > I can think of two benefits off the top of my head. 1. Subversion "tags" don't work for me. I think this is because I have deleted files since the last tag, I posted a message here, nobody was able to help. So I don't always do it when I should. Only a small thing, but one that annoys me. Actually I find the whole idea of tags in subversion very clumsy to use in any meaningful way. 2. Sometimes I make repeated mistakes when building a package; under subversion I have to make a new commit for each one before testing. Under git, I can test it with a local commit, and amend the commit if required before pushing it. 3. With git it is rather obvious when there is a new upstream branch (git fetch will tell you). With subversion, it is easy to miss, I think it requires manual checking. Recently, I have duplicated efforts to support Python3 in a package because I didn't notice it was committed in another branch. Oh, wait, that was three. So sorry. Also, sometimes I find subversion can be very slow when it needs to access the remote server. I am sure there are more reasons, these are the ones that have annoyed me recently. Unlike some, I am happy to continue using subversion. However I feel I could do a better, more professional job with git. -- Brian May
Re: Proposed git migration plan
Brian May writes: > 2. Sometimes I make repeated mistakes when building a package; under > subversion I have to make a new commit for each one before testing. Why is that? I'm testing my uncommitted changes with svn-buildpackage --svn-ignore-new --svn-builder=pdebuild and it seems to work very well. Best, -Nikolaus (who wishes for a decent mercurial-buildpackage) -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq9tmn97@vostro.rath.org
Re: Proposed git migration plan
❦ 27 août 2014 18:11 -0700, Nikolaus Rath :
>> 2. Sometimes I make repeated mistakes when building a package; under
>> subversion I have to make a new commit for each one before testing.
>
> Why is that? I'm testing my uncommitted changes with
>
> svn-buildpackage --svn-ignore-new --svn-builder=pdebuild
>
> and it seems to work very well.
I am also missing the ability to rewrite history from git. Of course,
you can use --svn-ignore-new but usually, you do not check everything
before each commit. You have different things to check: does the package
build, does it pass lintian, does it contain everything expected, does
it work? Working offline and rewriting history allows one to do many
changes and fix them once errors are discovered.
There are also situations where you just cannot tests your change. For
example, if you are offline with missing dependencies. Or over an
expensive Internet mobile plan. You can still do a lot of work with git
and test that when home and fixing the individual commits.
--
panic ("No CPUs found. System halted.\n");
2.4.3 linux/arch/parisc/kernel/setup.c
signature.asc
Description: PGP signature
