On Wed, Aug 27, 2008 at 10:32 PM, Jorge Godoy <[EMAIL PROTECTED]> wrote: > 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. > who said that mercurial isn't compatible? in fact it has several ways http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion
The suggestion here is to eliminate having SVN + something else, and replace everything with just a DVCS. >> - 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? > because when someone wants to publish his own branch trac is suboptimal, in the end is just too complicated for a temporal repo to show off some idea. >> - 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). > Since we have several people pulling changes from other repo's you have more eyes looking at the code. On top of that if the stable repo has flew people on it (for example only the maintainer of the branch) then it means that person will review all changes that go into that repo. Since code is moved around a lot more people see it which as linux (the kernel) has shown us reduces the amount of bugs push out. > Reverting bad changes is doable in all VCS. > that fixing the problem after it happens, not preventing it. > >> - 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. > This is not true, if you forget to push your changes to the tg server then too bad for you, you won't get on the release notes. there is no way (unless intentional) that you could push half a feature into tip. Well actually there is you can do export/import but that goes into the intentional. >> - 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? > sorry I left out a word there that mislead you "build on top of open source". Anyway what I wanted to say here is represented by the following scenario: you find a bug and fix it (with tests and everything), you open a ticket in trac, because you want someone to review it (or worse you don't have commit access), now you need to deploy said app with this patched TG. In a centralized system you will have to remind everyone (or write a script) to run your patch every time something is installed. In a distributed world you just clone the repo and the rest of the process is exactly the same. of course you could just generate egg files from the patched trunk but that means distributing things and a bunch of complications you don't get by just using several repositories. >> - 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. > Yes indeed there is no requirement for the above structure (although everyone does it) and disk-wise there isn't a problem either. The problem is visually why do I have to have that structure? why tags need to sit around in directories when they can be hidden inside the .hg dir? trunk/branches&tags are human conventions as you said, now do you have a checkout of the whole directory structure of TG? no one does that therefore you end up with a bunch of checkouts which represent a part of the repo which isn't very nice. This falls into the "I don't like it" category so your free to disagree :) >> - 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. you never lost credentials to a server? good for you, it's not very nice. > > 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). > most hosting providers back things up at most ones every day, TG current is 1 per day, 1 per week if I recall correctly. which means a crash & restore from backup could potentially lose you 1 full day of changes. the fact that each mercurial repo is a backup means there is zero chance of losing any code that was live at the site. >> - 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"... > yes 1 exception. is that enough not to switch? if so then why didn't we stick with CVS. it's "almost" the same as svn, with some "exceptions" like proper rename, and no locks. >> - 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. The first problem is that trac (main released stable non-patched) can't handle multiple svn repositories so the one shell script doesn't happens, so having several svn repositories isn't that simple. > > You can even automate Trac creation and configuration (I do that, it works > really well). > yes this is one of Mark's original points. Alberto did it for toscawidgets.org and he did a great job at it so (he said) we should use it. Did you did the same for svn? >> - 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). > why you say that. it's not like we are going to have a zillion repo's in a zillion servers. they are all going to be in hg.turbogears.org (or whatever it ends up being), and they all have the same place. Take a look at http://pylonshq.com/hg if you want webhelpers you checkout the following URL http://pylonshq.com/hg/webhelpers/ if you want pylons trunk you go here http://pylonshq.com/hg/pylons-dev/ how is that different from tg's svn? from the user perspective it's exactly the same. From the developer perspective it's a whole different thing with independent repo's and commit numbers, totally atomic clones and no way to leak from one part to the other. >> - RSS feeds customized per project, for free > > Doable with post-commit hooks. Configuration automated by the same shell > script mentioned above... > but not out of the box. where is it now? oh yes in a tg-tickets mailing list that stop working a while ago and the keys got lost. >> - 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? > because DVCS merge kicks svn's ***, you don't have to ask me everyone agrees on that. which is why svn1.5 worked so much on fixing it a little. >> - 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. how about the unreliable and unavailable? As for having everything since day 1, ones a bug is found in trunk/tip/whatever you need to go back to all the deployed stuff and fix it. Which means knowing when the bug was introduced is a huge plus since you only need to patch from that day to know. Some app's stay up for a lot longer than what someone could think of. > >> - 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. > again, the proposition here is to eliminate the need for svk or git-svn or hg-svn, and just keep everything speaking the same language. > > > 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. > All 4 of Mark's original ideas are valid, plus offline commits as several others have suggested, plus the ideas I posted that you didn't reject, plus the ones where I think your objections are not valid :) > > > -- > Jorge Godoy <[EMAIL PROTECTED]> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
