Em Friday 22 August 2008 04:16:53 Jorge Vargas escreveu: > > - branches, especially private ones, are awesome. For example I run my > own webhelpers private branch for one of my GAE projects, I got full > rev history, I can commit whatever I want, everything works. If some > of that code needs to move out into webhelpers tip, export/import and > done, and if some of that code is too specific for my app (or the > maintainers of tip don't want it) I can keep it without any troubles.
Other DVCS that are compatible with SVN would allow you to do the same without any change to the main repository -- i.e., you could get that without impacting everyone else. > - hgwebdir is a great tool, the closest thing to it on the svn world is > trac. So it also allows you to have a Wiki with docs, bug tracking system and everything else that Trac does? Or is it a minimized version of Trac but with a better file navigator? What would better file navigation bring to the project that would justify "changing" from SVN to HG? > - there is no fricking .svn on every folder. I use grep a lot and > that annoys me a LOT. Yep. I have a "grep -v .svn" alias for that. :-) > - in theory there is less chance of breaking the trunk,tip as you will > commit a set of changes that actually work. Even better if we have > someone in charge of doing code reviews he could filter bad commits. > this one is kind of a shocker: I didn't get this. What will prevent someone from commiting bad code? In my experience the only thing that does that is the requirement that unit tests be coded and then have then run on a commit hook, rejecting the commit if anything fails (and then nothing prevents the unit test from being deleted / not written and having bad code commited). Reverting bad changes is doable in all VCS. > - you don't need to be distributed if all developers push their > changes after commits, you get all the goodies and are still > "centralized". Problem here is the "if". According to Murphy's law, this won't happen so you'll end up with fragmented sources for code. > - you can have and maintain private forks better, I know this one > isn't a biggie for an open source project but it's good for the hybrid > model most of us use (charge customers for software build on open > source). You charge your customers for TG code that you write? > - I always found the /trunk /branches/ /tags hardcoded dirs a bad idea > for my projects. Ones it gets large you either have to make your / > grow a lot, or start checking out your trunk, and the branches you are > actually working on. On the other hand mercurial manages this > transparently. I couldn't understand what you were trying to say. If you could explain it better, I'd appreciate. The names you cite are just a convention and aren't a requirement for anything. We (human beings) do that because we like grouping similar things. This arrangement uses disk savvy implementations so there's no loss here. > - You can rebuild from crashes (or as it happen to me, getting locked > out of the server, I lost a lot of revision history on svn ones) with > mercurial this will never happen. Never? Hard to believe. Anyway, if you don't use the DB option and uses "fsfs" type for storing files then you can simply back them up and restore as you do with any file on your hard drive. There will be no DB corruption (there's no DB). > - the learning curve is minimal, almost all svn commands map 1-1 to hg > commands, so the only thing you need to learn is all the goodies hg > has, the only exception I can think of is hg revert. "almost", "exception"... > - take a look at http://svn.turbogears.org/ we have at least 6-7 > projects on that first level. If you go to > http://svn.turbogears.org/projects/ it's over 20. to svn they are all > the same thing. Now why we got there? because svn is very complex to > administer and having multiple repo's it's a pain. I don't think so. I think that this got to be like that because we didn't care to plan for this type of contribution. Creating a new repository is just a matter of running one shell script with a batch of commands and that's it. You can even automate Trac creation and configuration (I do that, it works really well). > - so this means that someone working on TG1, TG2 and some of the extra > packages will have to check out several parts of that big repo, which > is clumsy, you know it is. Is it? I'd thik it would be clumsier to go to different servers (repositories, whatever) to get all components (specially "if" they are not commited to the central server). > - RSS feeds customized per project, for free Doable with post-commit hooks. Configuration automated by the same shell script mentioned above... > - TG1 refuses to die (no offense) and now that it has gone to CP3 I > don't think it will be gone in a near future, which means that TG1 and > TG2 will live together, having each on it's own repo and merging > changes from one to the other (if any) will be very easy. Isn't it easy today? Just merge... Why switching tools will make it easier? > - we could host our own copies of upstream repo's, this is good in > case it's unreliable, unavaliable or even worst goes closed source Copying the whole history of commits since day 1? I don't see how that could be useful if it goes closed source... Having the latest code would be the most important thing... The only benefit is if you want to fork some code and only decides doing that after the licensing change. > - forks are good :) seriously if for some reason we need to fork > (temporally) from any of the pylons's components it can be done and > then the same release process for TG can be maintain. Same can be done with other DVCS without any change on the existing repository. I have the same question that I posted on the other list: What will changing the main repository from on VCS to another gives us? I haven't seen anything that can't be obtained today. -- Jorge Godoy <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part.
