From: Beni C. <cb...@us...> - 2004-05-15 21:18:15
|
From observing Docutils CVS traffic, it seems that we do more copying and moving of files most other projects. This is mainly because of the sandbox that is to a large degree used instead of development on branches (mainly to avoid the horrors of CVS with respect to tagging and branching). Thus, the Docutils project already came to use the model of `branching by copying`_ that is the central improvement of Subversion_ over CVS. The differences that allows Subversion to work with it smoothly are: 1. It is capable of recording file history accross renames/copies. 2. Its repository format allows to copy arbitrarily large directory trees with O(1) cost in speed and repository space. Therefore, Subversion should provide an especially noticable benefit to Docutils, with easier leraning curve (since we already use the same scheme; note that we don't have to call the branches directory ``branches`` - ``sandbox`` would work just as well...). The questions are: 1. Does a transition to Subversion sound a good idea to you at all? As for performing the transition itself, the cvs2svn script is nowdays rumored to be very solid; Xiph.org has recently performed a complete CVS->SVN conversion as an example. 2. Where to find hosting? SourceForge doesn't provide svn services and doesn't plan to in the close future. There is opensvn_, which while nice free and useful doesn't seem solid enough (backups, support, etc.) for a project of Docutils' size. So we are probably not going to switch now anyway, only decide wehther we want to. .. _Subversion: http://subversion.tigris.org/ .. _branching by copying: http://svnbook.red-bean.com/svnbook/ch04s02.html .. _opensvn: http://opensvn.csie.org/ -- Beni Cherniavsky <cb...@us...> Note: I can only read email on week-ends... |
From: David G. <go...@py...> - 2004-05-15 21:33:18
|
I'd love to switch to Subversion, but hosting the repository is the barrier. We really rely on SourceForge, and until there's a Subversion repository as reliable as SF, I don't see us switching. -- David Goodger |
From: William D. <wi...@fl...> - 2004-05-16 09:13:12
|
David Goodger <go...@py...> writes: > I'd love to switch to Subversion, but hosting the repository is > the barrier. We really rely on SourceForge, and until there's > a Subversion repository as reliable as SF, I don't see us > switching. To don't rely more on *any* server, we could switch to Arch, we'll have the same benefits as subversion for moving files, and somes more : to create distributed and independants branchs. Don't you like to can commit when you are away with your laptop ? We'll also don't need to give a write access to everybody who want a sandbox... (we are 61 developers !!!) The learning curve seems to be more difficult, because of the different phylosophy, but arch follow the KISS ! So when you understand it, it's become very light. One example : - Somebody want to create a new writer He first create a branch of the mainline on his laptop, and begin to hack on his writer (with somes commit to keep a trace of his work). In the time, the mainline fix somes bugs. He can keep in sync with it with "star-merge" or "update". When he finish (or before) his writer, he publish his work on any http server and ask people to look at it (his branch will be exactly like the mainline + his writer) When everybody is agree to incorporate it to the mainline, he ask the dictator or one of his slave with write acces to do a star-merge on the mainline. The kernel devs work like this i think (with bitkeeper). Other example : - somes persons want to make a sprint One create a branch from the mainline on an other server. we give write access to all the developers arount the table. Everybody hack and make a serie of update/commit, exactly like with cvs. In the end, if the result of the sprint is great, this branch is merged with the mainline. And finaly, there is one similarity with docutils : an arch repository can be read by humain, it's just somes log-files, diff and tar. So tomorow we can put it on sourceforge. the tutorial : http://gnuarch.org/tutorial/html/arch.html the wiki with answer to somes questions : http://wiki.gnuarch.org one example of an user-friendly browser who can maybe help to understand the concept : http://migo.sixbit.org/software/archzoom/ I'm far to be a guru of arch, but if you've questions that i can't answer, i'll ask on the arch mailing-list. -- William Dode - http://flibuste.net |
From: Ian B. <ia...@co...> - 2004-05-17 00:31:46
|
On May 16, 2004, at 4:12 AM, William Dode wrote: > To don't rely more on *any* server, we could switch to Arch, we'll have > the same benefits as subversion for moving files, and somes more : to > create distributed and independants branchs. > Don't you like to can commit when you are away with your laptop ? > We'll also don't need to give a write access to everybody who want a > sandbox... (we are 61 developers !!!) This is a good argument against decentralization: http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot Also, Subversion is very easy to learn if you know CVS. -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |
From: Adrien B. <adr...@fr...> - 2004-05-17 05:47:31
|
On Monday 17 May 2004 02:31, Ian Bicking wrote: > > This is a good argument against decentralization: > http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot I'm not convinced, but I have to take a train in a few minutes, so that's all I say for now. ;) Oh well, let's just say that this article main argument seems to be "Here are several major problems [even this is arguable] about Linux development. Linux development is decentralized. Therefore, decentralized development has major problems." Uh oh. > Also, Subversion is very easy to learn if you know CVS. That is true. Arch has a steeper learning curve. -- adr...@fr... - http://adrien.beau.free.fr/ |
From: William D. <wi...@fl...> - 2004-05-17 08:22:23
|
Ian Bicking <ia...@co...> writes: > On May 16, 2004, at 4:12 AM, William Dode wrote: >> To don't rely more on *any* server, we could switch to Arch, we'll hav= e >> the same benefits as subversion for moving files, and somes more : to >> create distributed and independants branchs. >> Don't you like to can commit when you are away with your laptop ? >> We'll also don't need to give a write access to everybody who want a >> sandbox... (we are 61 developers !!!) > > This is a good argument against decentralization: > http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot wich one for us ? I think for docutils we are more in the situation of : =AB Although a changeset-oriented source control tool is useful in many contexts (offline development on a laptop and private branches of a project, to name two) =BB I see two main problem with centralized system : - need to find a server, and depend of the this server (is it online when you need to commit ? and are we online also ?) - need to give write access to all the developers. I've no experience with big centralized development, but for my own litle projects, it help me a lot after CVS. Even when you work alone on a project, the branching system and the possibility to commit on a laptop is very good and very easy to install and use. But anyway, you can also use arch in a centralized manner, like i show with the example of a sprint. (the shared file-system could be online of course) > > Also, Subversion is very easy to learn if you know CVS. On one part, subversion is maybe easy to learn, but it's not easy to find a server, and impossible on sourceforge now... On second part, we don't change a version control system every day ! So it's a good time to learn, why do you want to learn it quickly ? Specialy you ;-) --=20 William Dode - http://flibuste.net |
From: Ian B. <ia...@co...> - 2004-05-17 15:59:05
|
William Dode wrote: > Ian Bicking <ia...@co...> writes: >>On May 16, 2004, at 4:12 AM, William Dode wrote: >> >>>To don't rely more on *any* server, we could switch to Arch, we'll hav= e >>>the same benefits as subversion for moving files, and somes more : to >>>create distributed and independants branchs. >>>Don't you like to can commit when you are away with your laptop ? >>>We'll also don't need to give a write access to everybody who want a >>>sandbox... (we are 61 developers !!!) >> >>This is a good argument against decentralization: >> http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot >=20 >=20 > wich one for us ? > I think for docutils we are more in the situation of : >=20 > =AB Although a changeset-oriented source control tool is useful in many > contexts (offline development on a laptop and private branches of a > project, to name two) =BB With Subversion you do have to be connected to do some operations=20 (though less so than CVS). I don't think it's that bad. I don't see any reason why docutils would need private branches. I=20 would assume people will still have "home" directories, where they can=20 do their own development, but these would be public, just like the=20 sandbox is now. They *should* be public. > I see two main problem with centralized system : > - need to find a server, and depend of the this server (is it online > when you need to commit ? and are we online also ?) Also true with Arch. Docutils will be primarily using centralized=20 development no matter what the tool, and there needs to be a canonical=20 repository where people share and cooperate on a main trunk of=20 development. It's not that hard to find a server -- I've already=20 mentioned two options (and personally I wouldn't want to babysit a=20 shared-file repository, with the permission issues that are likely to=20 occur periodically, lock issues, file sharing, etc., when the Subversion=20 server has been easy and reliable). > - need to give write access to all the developers. Has this been a problem? It seems like most people who want write=20 access have been given it, and it works just fine. If there are=20 problems, the centralized model is better because those problems will be=20 identified early, and can be corrected -- i.e., someone will commit a=20 change that has problems (buggy, doesn't fit style, etc), and someone=20 will notice it and ask the author to correct the problems. The author=20 has learned something, they haven't done a lot of parallel development=20 in an improper style, and it's all okay. The whole point of version=20 control is that shared access is safe, because there's a log, everything=20 can be undone, etc. (As long as people pay attention to what each other=20 does) >>Also, Subversion is very easy to learn if you know CVS. >=20 >=20 > On one part, subversion is maybe easy to learn, but it's not easy to > find a server, and impossible on sourceforge now... > On second part, we don't change a version control system every day ! So > it's a good time to learn, why do you want to learn it quickly ? > Specialy you ;-) Part of it is what "we" means. Contributors come and go. A CVS-like=20 system will allow them to use their experience to quickly get working --=20 I don't know about other people, but CVS took me a significant amount of=20 time to get used to, in part because it's crufty, but in part because I=20 had to understand its particular model (which is one Subversion copies,=20 but Arch definitely does not). There are other distributed source=20 control systems which look more like CVS, but then there's the viability=20 issue. Subversion is definitely viable, and I think will be used by=20 many projects projects. I've already moved all my projects over. Zope=20 is also moving to Subversion. I'd credit this to the ease of tranfering=20 skills from CVS, and I'd expect that trend to continue. --=20 Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: William D. <wi...@fl...> - 2004-05-17 21:25:38
|
Ian Bicking <ia...@co...> writes: > William Dode wrote: >> Ian Bicking <ia...@co...> writes: >>>On May 16, 2004, at 4:12 AM, William Dode wrote: >>> >>>>To don't rely more on *any* server, we could switch to Arch, we'll ha= ve >>>>the same benefits as subversion for moving files, and somes more : to >>>>create distributed and independants branchs. >>>>Don't you like to can commit when you are away with your laptop ? >>>>We'll also don't need to give a write access to everybody who want a >>>>sandbox... (we are 61 developers !!!) >>> >>>This is a good argument against decentralization: >>> http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot >> wich one for us ? >> I think for docutils we are more in the situation of : >> =AB Although a changeset-oriented source control tool is useful in man= y >> contexts (offline development on a laptop and private branches of a >> project, to name two) =BB > > With Subversion you do have to be connected to do some operations > (though less so than CVS). I don't think it's that bad. It's not bad when it works and when you are online. In France for example the biggest hosting server for free softwares (tuxfamily) was cracked, and finaly had to stop for somes month. Maybe it's because of this that a lot french people are looking at arch now... > > I don't see any reason why docutils would need private branches. I > would assume people will still have "home" directories, where they can > do their own development, but these would be public, just like the > sandbox is now. They *should* be public. To make branch doesn't means that they will not be public. > >> I see two main problem with centralized system : >> - need to find a server, and depend of the this server (is it online >> when you need to commit ? and are we online also ?) > > Also true with Arch. Docutils will be primarily using centralized > development no matter what the tool, and there needs to be a canonical > repository where people share and cooperate on a main trunk of > development. It's not that hard to find a server -- I've already > mentioned two options (and personally I wouldn't want to babysit a > shared-file repository, with the permission issues that are likely to > occur periodically, lock issues, file sharing, etc., when the > Subversion server has been easy and reliable). When i see the commits on the current cvs, i see people hacking on their sandbox or on their writers, but not a lot on the same part, the core for example. It's why i thought imediatly to arch. > >> - need to give write access to all the developers. > > Has this been a problem? It seems like most people who want write > access have been given it, and it works just fine. If there are > problems, the centralized model is better because those problems will > be identified early, and can be corrected -- i.e., someone will commit > a change that has problems (buggy, doesn't fit style, etc), and > someone will notice it and ask the author to correct the problems. > The author has learned something, they haven't done a lot of parallel > development in an improper style, and it's all okay. The whole point > of version control is that shared access is safe, because there's a > log, everything can be undone, etc. (As long as people pay attention > to what each other does) It's not a problem to give access to developpers, when i started to hack on docutils, david gave me immediatly an access. But i was a little bit afraid to commit and break the main tree... So finaly i did'nt use it a lot. And i see that for 61 developpers there is not a lot of them who commit somethings. With subervsion i know that you can give access to somes parts only. So, an other example : I want to try to rewrite a part of the core of docutils. With arch, i will make my branch, rewrite the code i want, it will be long, but i can keep in sync with the mainline. If i want to share my work i publish it that others peoples can work with me (we'll merge our branchs together). And finaly when it's finish and fully tested and aproved, it's ready to merge with the mainline. I like this model. And i cannot imagine now to commit something on the core of docutils or ask david to create a branch specialy for this.=20 Like we said before, docutils cannot have a dev-line and a main-line,=20 it's why it will be good to can make quickly a little branch to test=20 somethings without need to ask anybody... > >>>Also, Subversion is very easy to learn if you know CVS. >> On one part, subversion is maybe easy to learn, but it's not easy to >> find a server, and impossible on sourceforge now... >> On second part, we don't change a version control system every day ! S= o >> it's a good time to learn, why do you want to learn it quickly ? >> Specialy you ;-) > > Part of it is what "we" means. Contributors come and go. A CVS-like s= ystem will allow them to use their experience to quickly get working --=20 > I don't know about other people, but CVS took me a significant amount > of time to get used to, in part because it's crufty, but in part > because I had to understand its particular model (which is one > Subversion copies, but Arch definitely does not). There are other > distributed source control systems which look more like CVS, but then > there's the viability issue. Subversion is definitely viable, and I > think will be used by many projects projects. I've already moved all > my projects over. Zope is also moving to Subversion. I'd credit this > to the ease of tranfering skills from CVS, and I'd expect that trend > to continue. Sure, arch is an other model, it's not specialy difficult, it's just different, it's why i gave somes examples. --=20 William Dode - http://flibuste.net |
From: Ian B. <ia...@co...> - 2004-05-17 21:45:15
|
William Dode wrote: > Ian Bicking <ia...@co...> writes: [snip] >>With Subversion you do have to be connected to do some operations >>(though less so than CVS). I don't think it's that bad. > > > It's not bad when it works and when you are online. > In France for example the biggest hosting server for free softwares > (tuxfamily) was cracked, and finaly had to stop for somes month. Maybe > it's because of this that a lot french people are looking at arch now... I really don't see how Arch helps that much in this case. If people want to share their work, they need a server. Arch allows a person to go off on their own and do work in a private, disconnected environment -- but if you want to share your work, you're in the same situation as you'd be with Subversion, where you need a well-connected host. Unless you do ad hoc sharing, where you pass patch files back and forth and so on... but that doesn't seem to make much sense unless you really *have* to do that for some reason. >>I don't see any reason why docutils would need private branches. I >>would assume people will still have "home" directories, where they can >>do their own development, but these would be public, just like the >>sandbox is now. They *should* be public. > > To make branch doesn't means that they will not be public. Well, you can't make them public unless you have a server -- which compounds the server problem, because instead of one server that works for all of us, you need one server for each person/branch. [snip] > It's not a problem to give access to developpers, when i started to hack > on docutils, david gave me immediatly an access. But i was a little bit > afraid to commit and break the main tree... So finaly i did'nt use it a > lot. And i see that for 61 developpers there is not a lot of them who > commit somethings. > With subervsion i know that you can give access to somes parts only. > So, an other example : > I want to try to rewrite a part of the core of docutils. With arch, i > will make my branch, rewrite the code i want, it will be long, but i can > keep in sync with the mainline. If i want to share my work i publish it > that others peoples can work with me (we'll merge our branchs > together). And finaly when it's finish and fully tested and aproved, > it's ready to merge with the mainline. > I like this model. And i cannot imagine now to commit something on the > core of docutils or ask david to create a branch specialy for this. > Like we said before, docutils cannot have a dev-line and a main-line, > it's why it will be good to can make quickly a little branch to test > somethings without need to ask anybody... You can do this pretty easily in Subversion -- anyone can make a branch, and put that branch someplace in the tree where it is (by convention) "private", like the sandbox. You just do: svn cp trunk/docutils home/ianb/docutils (You can lay the files out several ways, all these names are just conventions we'd have to agree on) Then home/ianb/docutils is a branch, and is managed completely separately from trunk/docutils. (IMHO, It's much easier to think about branching in term of copying than CVS's model.) I think Arch has some better tools for merging branches, but I'm optimistic that this will improve with Subversion -- I don't think there's any architectural reason Subversion is lacking, it just wasn't a priority. Then, when you are done with your branch you merge your files back in and delete the directory from the repository. Indeed, CVS isn't great for this, but this is something Subversion improves. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: William D. <wi...@fl...> - 2004-05-17 22:22:27
|
Ian Bicking <ia...@co...> writes: > William Dode wrote: >> Ian Bicking <ia...@co...> writes: > [snip] >>>With Subversion you do have to be connected to do some operations >>>(though less so than CVS). I don't think it's that bad. >> It's not bad when it works and when you are online. >> In France for example the biggest hosting server for free softwares >> (tuxfamily) was cracked, and finaly had to stop for somes month. Maybe >> it's because of this that a lot french people are looking at arch now... > > I really don't see how Arch helps that much in this case. If people > want to share their work, they need a server. Arch allows a person to > go off on their own and do work in a private, disconnected environment > -- but if you want to share your work, you're in the same situation as > you'd be with Subversion, where you need a well-connected host. > Unless you do ad hoc sharing, where you pass patch files back and > forth and so on... but that doesn't seem to make much sense unless you > really *have* to do that for some reason. The difference is that there is nothing to run on the server side for arch. An http server of static files is enough for example. So it's really easy to find. My first reason to move to arch was : how i can use a better tools than cvs on my woody server. And after that, how i was happy to can work offline on my laptop :-). Simple and efficient. > >>>I don't see any reason why docutils would need private branches. I >>>would assume people will still have "home" directories, where they can >>>do their own development, but these would be public, just like the >>>sandbox is now. They *should* be public. >> To make branch doesn't means that they will not be public. > > Well, you can't make them public unless you have a server -- which > compounds the server problem, because instead of one server that works > for all of us, you need one server for each person/branch. > > [snip] >> It's not a problem to give access to developpers, when i started to hack >> on docutils, david gave me immediatly an access. But i was a little bit >> afraid to commit and break the main tree... So finaly i did'nt use it a >> lot. And i see that for 61 developpers there is not a lot of them who >> commit somethings. >> With subervsion i know that you can give access to somes parts only. >> So, an other example : >> I want to try to rewrite a part of the core of docutils. With arch, i >> will make my branch, rewrite the code i want, it will be long, but i can >> keep in sync with the mainline. If i want to share my work i publish it >> that others peoples can work with me (we'll merge our branchs >> together). And finaly when it's finish and fully tested and aproved, >> it's ready to merge with the mainline. >> I like this model. And i cannot imagine now to commit something on the >> core of docutils or ask david to create a branch specialy for >> this. Like we said before, docutils cannot have a dev-line and a >> main-line, it's why it will be good to can make quickly a little >> branch to test somethings without need to ask anybody... > > You can do this pretty easily in Subversion -- anyone can make a > branch, and put that branch someplace in the tree where it is (by > convention) "private", like the sandbox. You just do: > > svn cp trunk/docutils home/ianb/docutils > > (You can lay the files out several ways, all these names are just > conventions we'd have to agree on) Then home/ianb/docutils is a > branch, and is managed completely separately from trunk/docutils. > (IMHO, It's much easier to think about branching in term of copying > than CVS's model.) I think Arch has some better tools for merging > branches, but I'm optimistic that this will improve with Subversion -- > I don't think there's any architectural reason Subversion is lacking, > it just wasn't a priority. If we are optimistic we can hope to have a good gateway between subversion and arch ! -- William Dode - http://flibuste.net |
From: David G. <go...@py...> - 2004-05-17 21:45:04
|
William Dode wrote: > I like this model. And i cannot imagine now to commit something on > the core of docutils or ask david to create a branch specialy for > this. You don't need to ask. You can create a branch any time you like with CVS, without any special permission. > Like we said before, docutils cannot have a dev-line and a > main-line, Docutils *can* have a main branch/trunk and a dev branch. It's just that we choose not to. Arch and Subversion probably make these operations much easier, but it can be done in CVS. -- David Goodger |
From: William D. <wi...@fl...> - 2004-05-17 22:35:23
|
David Goodger <go...@py...> writes: > William Dode wrote: > > I like this model. And i cannot imagine now to commit something on > > the core of docutils or ask david to create a branch specialy for > > this. > > You don't need to ask. You can create a branch any time you like with > CVS, without any special permission. > > > Like we said before, docutils cannot have a dev-line and a > > main-line, > > Docutils *can* have a main branch/trunk and a dev branch. It's just > that we choose not to. > > Arch and Subversion probably make these operations much easier, but it > can be done in CVS. Of course, i understand that we can make branch if we really want. Even i can make my arch branch from the cvs and work offline. I just wanted to give somes examples (with my poor english !), not to say that we need absolutly to work like this. -- William Dode - http://flibuste.net |
From: Ian B. <ia...@co...> - 2004-05-18 03:30:10
|
On May 17, 2004, at 5:22 PM, William Dode wrote: > Ian Bicking <ia...@co...> writes: >> I really don't see how Arch helps that much in this case. If people >> want to share their work, they need a server. Arch allows a person to >> go off on their own and do work in a private, disconnected environment >> -- but if you want to share your work, you're in the same situation as >> you'd be with Subversion, where you need a well-connected host. >> Unless you do ad hoc sharing, where you pass patch files back and >> forth and so on... but that doesn't seem to make much sense unless you >> really *have* to do that for some reason. > > The difference is that there is nothing to run on the server side for > arch. An http server of static files is enough for example. So it's > really easy to find. Ok, that works for read-only repositories, but what about writing? Does it work via ssh, with the client effectively run on the remote machine (like CVS does on SourceForge, and like one of the Subversion options, but not the one I like)? I haven't found that to be a particularly satisfying setup, nor one that's easy to support. Or does it have an over-the-wire protocol, besides file-based access? (Like, I think Darcs has a CGI script that can be used as the server -- which would actually be a useful option for any of these systems) I guess this isn't what Arch is built for -- it's built for a single author per repository, with changesets being passed around asynchronously (email, FTP, etc). So if you want to run it in a centralized fashion, it's less impressive. -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |
From: William D. <wi...@fl...> - 2004-05-18 08:55:21
|
Ian Bicking <ia...@co...> writes: > On May 17, 2004, at 5:22 PM, William Dode wrote: >> Ian Bicking <ia...@co...> writes: >>> I really don't see how Arch helps that much in this case. If people >>> want to share their work, they need a server. Arch allows a person to >>> go off on their own and do work in a private, disconnected environment >>> -- but if you want to share your work, you're in the same situation as >>> you'd be with Subversion, where you need a well-connected host. >>> Unless you do ad hoc sharing, where you pass patch files back and >>> forth and so on... but that doesn't seem to make much sense unless you >>> really *have* to do that for some reason. >> >> The difference is that there is nothing to run on the server side for >> arch. An http server of static files is enough for example. So it's >> really easy to find. > > Ok, that works for read-only repositories, but what about writing? > Does it work via ssh, with the client effectively run on the remote > machine (like CVS does on SourceForge, and like one of the Subversion > options, but not the one I like)? You can write by ftp, ssh or webdav directly or by mirroring a local repository. But's it's really just a remote file system, not like cvs or subversion that need to run on the server. > I haven't found that to be a > particularly satisfying setup, nor one that's easy to support. It's possible but i think also that it's good for very few developers (the managers), and for sprint. The others developers have their own repositories. > Or > does it have an over-the-wire protocol, besides file-based access? > (Like, I think Darcs has a CGI script that can be used as the server > -- which would actually be a useful option for any of these systems) The cgi script of darcs is only to browse archive, like viewcvs or archzoom. For arch, what you want is arch-pqm, writen in python :-) : http://web.verbum.org/arch-pqm/ It run on the server and merge automaticaly the request of the developers. It use arch-hooks to prevent bad commit (not allowed, not signed, who don't pass somes tests...) There is also an archd server, who use twisted. > > I guess this isn't what Arch is built for -- it's built for a single > author per repository, with changesets being passed around > asynchronously (email, FTP, etc). So if you want to run it in a > centralized fashion, it's less impressive. I think also. One say that subervsion is centralized around repository and arch is centralized around people. Even if it's not a "strict" behaviour. -- William Dode - http://flibuste.net |
From: Felix W. <Fel...@gm...> - 2004-11-24 20:19:23
|
David Goodger wrote: > I'd love to switch to Subversion, but hosting the repository is > the barrier. We really rely on SourceForge, and until there's > a Subversion repository as reliable as SF, I don't see us > switching. What about BerliOS? They offer Subversion hosting, too. Documentation: http://developer.berlios.de/docman/?group_id=2 -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Felix W. <Fel...@gm...> - 2005-01-19 20:08:19
|
Felix Wiemann wrote: > The performance on BerliOS is quite good, by the way. Just wanted to add that SourceForge's performance is terrible right now. "cvs up" took 2:55 on 'docutils' and 15:17 on 'sandbox'. Minutes, not seconds. BerliOS-SVN takes about 3 seconds for doing svn up on working copies of either svn+ssh://<username>@svn.berlios.de/svnroot/repos/docutils/trunk/docutils or .../sandbox. When using anonymous access, it's even faster, because no SSH connection is needed: Working copies of svn://svn.berlios.de/docutils/trunk/docutils and .../sandbox take about 1 to 1.5 seconds to update. By the way, that repository has been created using cvs2svn, with FSFS as repository filesystem. If you're interested in browsing it, please take a look at <http://svn.berlios.de/viewcvs/docutils/>. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Felix W. <Fel...@gm...> - 2005-02-07 16:05:50
|
Felix Wiemann wrote: > Done. Just registered Docutils at BerliOS and set up a repository. I'm currently trying to get things working the way I want. I'll probably report back in a week or so. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Ian B. <ia...@co...> - 2004-05-15 22:06:23
|
On May 15, 2004, at 3:17 PM, Beni Cherniavsky wrote: > 2. Where to find hosting? SourceForge doesn't provide svn services > and doesn't plan to in the close future. There is opensvn_, which > while nice free and useful doesn't seem solid enough (backups, > support, etc.) for a project of Docutils' size. So we are probably > not going to switch now anyway, only decide wehther we want to. I've found Subversion maintenance to be pretty easy -- create the repository with "svnadmin create", set up the server in inetd, and do a little fiddling to set up email and user accounts, then it pretty much runs itself. Backups could be as simple as having some people here download dumps in a cron job. After that, all you really need is disk space on a reliable server. That should be possible to find without too much trouble. I have some space myself I could offer, and there's a number of other possibilities. It would probably be okay to set it up on the webwareforpython.org virtual server, for instance -- though it's not really up to me (though I'm not exactly sure who it is up to... but it probably won't be a problem). That server is hosted by Tummy, and they are active in the Python community, so I think they would also be helpful in terms of support, and generally sharing a server makes it less likely that the server will go into disrepair. -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |
From: A.M. K. <am...@ro...> - 2004-05-17 00:43:57
|
On Sat, May 15, 2004 at 11:17:54PM +0300, Beni Cherniavsky wrote: > 1. It is capable of recording file history accross renames/copies. Is it really capable of this? I thought renaming was implemented as an add + a delete, meaning that you can't actually follow the history of a file back to before it was renamed. --amk |
From: Ian B. <ia...@co...> - 2004-05-17 00:53:00
|
On May 16, 2004, at 7:50 PM, A.M. Kuchling wrote: > On Sat, May 15, 2004 at 11:17:54PM +0300, Beni Cherniavsky wrote: >> 1. It is capable of recording file history accross renames/copies. > > Is it really capable of this? I thought renaming was implemented as > an add + a delete, meaning that you can't actually follow the history > of a file back to before it was renamed. (Assuming we're talking about Subversion here...) Moving is implemented as a copy+delete, and the copy maintains the history of its original. Copies show up as "A" when you show their status, like an add, but that's just a shorthand. -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |
From: Fred L. D. Jr. <fd...@ac...> - 2004-05-17 03:39:00
|
On Sunday 16 May 2004 08:52 pm, Ian Bicking wrote: > Moving is implemented as a copy+delete, and the copy maintains the > history of its original. Copies show up as "A" when you show their > status, like an add, but that's just a shorthand. And with any copy, the history can be kept or discarded; the default is to keep the history. In this case, "svn stat" reports a "+" in addition to the "A". -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation |
From: Felix W. <Fel...@gm...> - 2005-01-18 21:36:13
|
[Replying on-list again 'cause I'm discussing things now and I don't want to exclude other people from the disussion.] David Goodger wrote: > Felix Wiemann wrote: > >> What do you think? Should I test if we get a proper repository using >> cvs2svn, and set up a project on BerliOS to test if their SSH access >> works well? Or rather not? > > I've used Subversion, and I like it (can't beat those instant diffs!), > but I don't think there's enough of a benefit to counter the work of > transferring the project to another site. The transferring itself should be easy; cvs2svn is reported to work quite well (so we wouldn't lose any history). The work for a developer amounts to downloading (and possibly compiling) a current Subversion client and checking out a working copy. Since it's very similar to CVS, the transition should be rather painless. Concerning the sandboxes, IMO we should offer but not force anyone to move to Subversion. So those who request it get their sandboxes moved to Subversion, and those who'd like to stay with CVS can continue to use CVS on SF.net. > If you'd like to try out BerliOS, please go ahead. Done. Just registered Docutils at BerliOS and set up a repository. If you want to test it yourself, please mail me your berlios username. > I'm happy staying with SourceForge for now. Just to clarify my point, I'm only suggesting moving with the repository. All other things (web site etc.) would remain on SF.net. > If we could be on both systems simultaneously, and keep both in sync, > then I might be more interested. That's too difficult and error-prone, IMO. The main reason why I would like to move to Subversion is that CVS's branching is bothering me terribly. Now I'd like to write some test cases for the plugin support, and I can't simply check them in because we can't afford having a failing test case in the trunk. With Subversion, I'd just quickly create a branch. And I've been posting patches in the past, where with Subversion I would have branched instead of wasting time on dealing with patches. And no, using CVS's branches are *not* an alternative. Nuff ranting. What I want to say is: With Subversion's copy-branches, we'd be able to speed up development. These are the issues I see with using Subversion: * We don't know BerliOS's long-term reliability (though I trust it's good). * Things like automatic EOL-conversion and keyword-substitution must be configured per-developer (using auto-props), not per-repository. It's only relevant to developers who want to *add* files, however. We could add a short section on setting up Subversion to a documentation file; and to catch those cases where a file is added using a mis-configured Subversion, I'd volunteer to write a checking-script which reports them, so we can correct them. * Every developer has SSH access to the repository. This means that the repository is not as safe as on SF.net. We could establish a backup policy to avoid damage. I have a rather fast internet connection now, so I could regularly pull backup copies of new revisions. * Every client starts its own SVN server instance. Thus the repository is more susceptible to locking problems, e.g. when a client is killed while accessing the repository. To avoid that, it seems best to use FSFS instead of BDB as repository filesystem, because FSFS is more robust in this regard. FSFS will also facilitate backuping. The performance on BerliOS is quite good, by the way. 'svn up' on a checkout of the empty directory svn.berlios.de/svnroot/repos/docutils took 3 seconds, whereas 'cvs up' in docutils/extras (only 3 files, unmodified of course) took 15 to 20 seconds. Comments? -- Felix Wiemann -- http://www.ososo.de/ |
From: Fred L. D. Jr. <fd...@ac...> - 2005-01-21 19:41:54
|
[David] > If we could be on both systems simultaneously, and keep both in sync, > then I might be more interested. That sounds like way more overhead and pain than is warranted. [Felix] > The main reason why I would like to move to Subversion is that CVS's > branching is bothering me terribly. Subversion branches are far better than CVS branches, as is the disconnected operation. > * Things like automatic EOL-conversion and keyword-substitution must be > configured per-developer (using auto-props), not per-repository. It's > only relevant to developers who want to *add* files, however. I think the Subversion crew plans to fix this for 2.0. It is a nuissance, but we've not found it prohibitive for Zope, which is a much larger project. > * Every developer has SSH access to the repository. This means that the > repository is not as safe as on SF.net. > > We could establish a backup policy to avoid damage. I have a rather > fast internet connection now, so I could regularly pull backup copies > of new revisions. This seems reasonable. > * Every client starts its own SVN server instance. Thus the repository > is more susceptible to locking problems, e.g. when a client is killed > while accessing the repository. > > To avoid that, it seems best to use FSFS instead of BDB as repository > filesystem, because FSFS is more robust in this regard. FSFS will > also facilitate backuping. Again, agreed. > The performance on BerliOS is quite good, by the way. 'svn up' on a SF's CVS performance was quite good at one point as well, once you got over the initial hiccup of not having direct access to the repository itself. :-) Scaling is a huge issue with these kinds of services, and the best bet is to not clump too much together; SF's problem is the sheer size of the beast. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> |