Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On 25-Mar-04, at 12:25 AM, Dustin Sallings wrote: It's definitely not a magic tool that makes bad code good and conflicting patches happy. It solves other problems, though. I don't think anything mentioned in this thread so far would be an enormous improvement over what we have now. However, I am still open to trying Arch or SVN: in the long run, I think the productivity gain from even an incremental improvement in the development toolset is worth a little effort in relearning and migration. But as I said, I don't think it's a critical issue, and if other developers would rather we stick with what we have, that's fine with me. WRT the relative merits of CVS, Arch, and SVN, David Wheeler (of Bricolage) has written an interesting article comparing the three systems: http://www.dwheeler.com/essays/scm.html I think the lack of good Win32 support (unless rectified before the release of 7.5) is a pretty major problem with Arch -- that alone might be sufficient to prevent us from adopting it. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
Dustin Sallings wrote: On Mar 24, 2004, at 20:29, Tom Lane wrote: Not here. You want me to trust some bit of code (with absolutely zero understanding of the source text it's hacking on) to figure out how to resolve conflicting patches? That sounds like a recipe for big-time unhappiness. The idea is that it's the responsibility of the branch owner to keep it up-to-date. For example, I've got a branch of tla (an arch implementation) I made soon after I started using it in order to add a command I wanted and refactor a bit of the insides. Over time, a lot of stuff has changed, but I still want my stuff to work, so as I update my branch against head of line, I make minor changes to it as things go. The difference is that instead of having a patch sitting in a queue somewhere suffering from bit-rot, you've got a pointer to a branch that you can merge when you get around to it. You can still view it as a diff if you want, but the diff you get six months after the original submission may be quite a bit different from what you would've got at the beginning if a lot of the code around it has changed. The difference here is that instead of submitting a patch for review, which is then frozen, the branch owner can (and that means some will, no matter what your intentions are) keep modifying the branch during the review process, other than just keeping it in sync with conflicting changes to the trunk. How do you plan to prevent that? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
Neil Conway said: I don't think anything mentioned in this thread so far would be an enormous improvement over what we have now. However, I am still open to trying Arch or SVN: in the long run, I think the productivity gain from even an incremental improvement in the development toolset is worth a little effort in relearning and migration. ISTM what we have here is a solution in search of a problem. When the committers tell us that there is a problem we should start looking. But as I said, I don't think it's a critical issue, and if other developers would rather we stick with what we have, that's fine with me. Maybe we should look at providing SVN as a project option on the new PGFoundry. That might let at least a part of the community get its toes wet with it, without disrupting the core in the first instance. I think the lack of good Win32 support (unless rectified before the release of 7.5) is a pretty major problem with Arch -- that alone might be sufficient to prevent us from adopting it. Agreed. It's a killer from my POV. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Thu, Mar 25, 2004 at 08:05:05AM -0500, Jan Wieck wrote: The difference here is that instead of submitting a patch for review, which is then frozen, the branch owner can (and that means some will, no matter what your intentions are) keep modifying the branch during the review process, other than just keeping it in sync with conflicting changes to the trunk. How do you plan to prevent that? I think it's much better for the reviewer to be able to see the history of changes of the patch (branch), without having to look at the whole patch again every time a small change is made to it. Or do you diff two versions of a patch to see if the author only changed what he says he changed? Wow, a diff of a diff, _that_ should be difficult to read. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Use it up, wear it out, make it do, or do without ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
Dustin Sallings wrote: You can use distributed revision control systems as centralized systems, but not vice-versa. Not true, the other way around exists, that is what svk does. As far as understanding the simplicity of arch (if you wanted to understand the problems it solves and implement it yourself), a really good presentation was posted today to the arch list that sums it up quickly and concisely. It's hard to go through that and not think, ``I could write this.'' http://web.verbum.org/tla/grokking-arch/grokking-arch.html Will read it, thanks. Regards, Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 25, 2004, at 5:05, Jan Wieck wrote: The difference here is that instead of submitting a patch for review, which is then frozen, the branch owner can (and that means some will, no matter what your intentions are) keep modifying the branch during the review process, other than just keeping it in sync with conflicting changes to the trunk. How do you plan to prevent that? You do both. Changesets are immutable. A patch cannot be modified. However, new patches can be added for tracking changes to the tree. You can review the original diff, and you can review how it's tracked head-of-line changes independently. You can take the original diff and manually wedge it in if you want, or you can see how the latest progress differs before submission. -- Dustin Sallings ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 25, 2004, at 1:21, Neil Conway wrote: I think the lack of good Win32 support (unless rectified before the release of 7.5) is a pretty major problem with Arch -- that alone might be sufficient to prevent us from adopting it. I don't do Windows, but my understanding is that tla is as well supported on Windows as postgres is. The design is fundamentally easy enough that a Windows user who cares could probably make a more suitable port for Windows than the UNIX guys are interested in making. I've seen such discussions on the list. -- Dustin Sallings ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 25, 2004, at 9:22, Magnus Naeslund(t) wrote: You can use distributed revision control systems as centralized systems, but not vice-versa. Not true, the other way around exists, that is what svk does. From its description, svk sounds like a completely different system: ``svk is a decentralized version control system written in Perl. It uses the subversion filesystem but provides some other powerful features.'' I.e. it seems to have a CVS vs. RCS relationship. It would be unfair to call CVS RCS. -- Dustin Sallings ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On 25-Mar-04, at 3:03 PM, Dustin Sallings wrote: I don't do Windows, but my understanding is that tla is as well supported on Windows as postgres is. David Wheeler disagrees: A serious weakness of arch is that it doesn't work well on Windows-based systems, and it's not clear if that will ever change. There are ports of arch, both non-native (Cygwin and Services for Unix) and a native port too. However, the current win32 port is only in its early stages, and the Win32 page on the Arch wiki says Arch was never intended to run on a non-POSIX system. Don't expect to have a full blown arch on your Microsoft computer. At least part of the problem is the long filenames used internally by arch; arch could certainly be modified to help, though there doesn't seem to be much movement in that direction. Other problematic areas include symbolic links, proper file permissions, and newline problems, as well as the general immaturity of the port as of March 2004. Some people don't think that poor Windows support is a problem; to me (and others!), that's a serious problem. Even if you don't use any Microsoft Windows systems, people don't want to use many different SCM systems, so if one can handle many environments and the other can't, people will use the one that can handle more environments. I think GNU Arch's use will be hampered by this lack of support as long as this is true, even for people who never use Windows; good native Windows support is very important for an SCM tool. -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
quote who=Dustin Sallings On Mar 25, 2004, at 1:21, Neil Conway wrote: I think the lack of good Win32 support (unless rectified before the release of 7.5) is a pretty major problem with Arch -- that alone might be sufficient to prevent us from adopting it. I don't do Windows, but my understanding is that tla is as well supported on Windows as postgres is. It that like the best beach volleball player in Antarctica? The Windows port of Postgresql is still in its infancy. It's coming along, but its not a finished product. The design is fundamentally easy enough that a Windows user who cares could probably make a more suitable port for Windows than the UNIX guys are interested in making. I've seen such discussions on the list. -- Dustin Sallings ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Tue, 23 Mar 2004 23:03:03 -0400 (AST) Marc G. Fournier [EMAIL PROTECTED] wrote: On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote: Which brings me to another question .. has anybody considered using subversion instead of CVS ? Why? not that I'm for a chance from something that isn't broken, but what advantages does subversion give us over what we already have? Subversion has lots of little benefits, but nothing that would be a major incentive to switch. The biggest benefits I can think of of the top of my head are: * Commits are actually atomic * protocol sends diffs in both directions which speeds up everything * branching and tagging are cheap constant time operations * the time it takes to make changes is based on the size of the change, not the size of the project * whole directories are versioned not just files. So for example if you for some reason wanted to rename src/backend/bootstrap.c to src/backend/bootup.c you wouldn't lose your revision history information. Same thing goes for complete reorganizations of the file layouts. * You can checkout parts of a project so if you need to fix a bug in 7.3.6's src/backend/ you only have to transfer that portion to you. * cvs diff ( well svn diff ) can be done offline. Same with 'status' which shows you your local modifications and 'revert' which reverts your changes back to your last checkout/update/etc. * Revisions numbers are repository wide instead of by file. You can refer to revision #14328 on hackers and everyone knows exactly what you are talking about and can switch their working copies to it easily ( svn switch -r 14328 ). It's sort of like having a tag for every commit made to the repository. It does have some downsides that I have found, most notibly that the size of your sources you have in your working copy are essentially doubled. There is a copy in your .svn directory that allows the offline status, diff, and revert commands to work. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 24, 2004, at 7:29, Frank Wiles wrote: [cool feature list] Arch has all of that except for the checking out part of a directory thing (would you really just check out the backend, submit a change, and not build and test it?). Additionally: * Repositories can be easily replicated so checkouts don't have to cross slow networks. I replicate every repository I work with to every machine I use. This is not only my backup strategy, but it makes checkouts faster. * You can work completely offline. In addition to being able to diff, undo changes, redo changes, etc... while offline, you can completely branch a project do multiple commits, and merge them back into the main archive when your plane lands. * Branches are not only cheap, but can easily cross repository boundaries. Any given user can create a branch from the head-of-line tree and maintain changes, and the head-of-line maintainers can pull those changes back in. * Its storage is immutable. It never modifies a file so it does not provide any possibility for corruption. This is also what makes replication so trivial. * Changesets have cryptographic checksums and may be cryptographically signed. Checkouts are authenticated against both of these. * Repositories can be accessed via a wide variety of means. Most of mine are local file, WebDAV, or SFTP. I allow read-only access via plain HTTP for anyone who wants to check out one of my projects. * Files can be tracked in a nearly (or completely) automatic fashion. Depending on project configuration, you can avoid having to interact with the revision control system other than writing changelogs and submitting patches. You an also use CVS-style tracking (manual adds and deletes (plus moves)) if you're more comfortable that way. * The design is way, way more simple and transparent, there are far fewer requirements. At least for me, this translates to a higher confidence that my stuff will always be available. The advantage I see to Subversion is that it's designed to be a better CVS. Since many people are comfortable with CVS and that style of centralized development, it may feel a little more natural for new converts. I feel that that's because it doesn't seem to take you very far. -- Dustin Sallings ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
Dustin Sallings wrote: On Mar 24, 2004, at 11:45, David Garamond wrote: So one might ask, what *will* motivate a die-hard CVS user? A real-close Bitkeeper clone? :-) Since it's illegal for anyone who uses Bitkeeper's free license to contribute to another project, does anyone know if there are any features in Bitkeeper missing from arch (specifically tla) that matter to developers? Or is there anything that may be a better match than arch? From what I read here and there, BitKeeper excels primarily in merging (good merging is apparently a very complex and hard problem) and GUI stuffs. Unfortunately, I have never and will never use Bitkeeper unless someone buys me a license for some reason. The distributed model seems like the only way to go for the open source development of the future. Not necessarily. For small to medium projects, a centralized model might work better. -- dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 24, 2004, at 13:22, David Garamond wrote: From what I read here and there, BitKeeper excels primarily in merging (good merging is apparently a very complex and hard problem) and GUI stuffs. There's not a lot of GUI in arch, but star-merge is fairly incredible. This is how tla (the main arch implementation) itself is developed. Lots of branches in lots of archives by lots of people. Unfortunately, I have never and will never use Bitkeeper unless someone buys me a license for some reason. The distributed model seems like the only way to go for the open source development of the future. Not necessarily. For small to medium projects, a centralized model might work better. I make use of the distributed nature of arch in my personal projects with no other developers. Offline work is just a branch in another archive that gets merged in later. Arch supports a centralized model as well as anything else, and I've got a big centralized set of archives, but I don't always have good connectivity to the master. This is where the distributed model wins. A server/network/whatever outage does not have the opportunity to slow me down. In the worst case, a long outage causes my branch to drift a little further from head of line than it normally would. -- Dustin Sallings ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
It does have some downsides that I have found, most notibly that the size of your sources you have in your working copy are essentially doubled. There is a copy in your .svn directory that allows the offline status, diff, and revert commands to work. What's needed is a good window client like WinCVS, however... Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
Christopher Kings-Lynne wrote: What's needed is a good window client like WinCVS, however... Chris There is a number of those, our shop uses (and makes programs for) both windows and unix (and might soon use mac's aswell), so it's very important that there exists a good client for each. Especially if you version html pages and such that is edited by people that isn't so techy. We're using TortoiseSvn right now, it's implemented as an explorer extension, so you just rightclick on a file or directory to update/commit/whatever. What i like with svn is that it's a nobrainer for old cvs guys like me to use it. It solves all the problems with CVS right now, and promises more features later on (like much better than CVS merging). The new buzz is distributed versioning systems these days, but i question if that is called for in the vast majority of projects out there. If the only reason is for offline work that can be achieved with subversion too, with svk for example (haven't tried it, but been told that it works fine). Svk handles or will(?) handle distributed repos in the bk sense aswell, i believe. But ofcourse arch has alot of features that are extremly cool, the reason why i didn't evaluate it further was that it didn't work on windows well, the fixed weird branching/version naming and the complexity of learning for our developers since they already use cvs. Surely the two systems should be evaluated against their competiors within the same distribution models, not cross the boundries, since the design is very different. Subversions strength is it's percieved simplicity, and archs strength is it's complexity. Regards, Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 24, 2004, at 18:22, Magnus Naeslund(t) wrote: The new buzz is distributed versioning systems these days, but i question if that is called for in the vast majority of projects out there. You can use distributed revision control systems as centralized systems, but not vice-versa. But ofcourse arch has alot of features that are extremly cool, the reason why i didn't evaluate it further was that it didn't work on windows well, the fixed weird branching/version naming and the complexity of learning for our developers since they already use cvs. Depends on how you set it up. In the recommended ``tagline'' method, you don't have to tell the revision control system when you add, remove, or move files (for the most part, binary files are not suitable for tagline). All you have to do is commit and type a message. Subversions strength is it's percieved simplicity, and archs strength is it's complexity. It is subversion's complexity that drove me away from it, in fact. Arch is incredibly simple all the way through. It sounds like it must be complex to be able to do all of the things people do with it, but it's most assuredly not. The requirements are few and basic (diff, patch, and tar). The most common stuff is at least as simple as CVS (commit, update and in explicit mode, add, rm, and mv), and the advanced stuff is just as easy as the simple stuff (star-merge, tag (branching), etc...). As far as understanding the simplicity of arch (if you wanted to understand the problems it solves and implement it yourself), a really good presentation was posted today to the arch list that sums it up quickly and concisely. It's hard to go through that and not think, ``I could write this.'' http://web.verbum.org/tla/grokking-arch/grokking-arch.html -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings [EMAIL PROTECTED] |Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L___ I hope the answer won't upset her. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Wednesday 24 March 2004 06:03 pm, Dustin Sallings wrote: There's not a lot of GUI in arch, but star-merge is fairly incredible. This is how tla (the main arch implementation) itself is developed. Lots of branches in lots of archives by lots of people. I would guess that better merging might be a real motivation for people. If a patch that takes a month to develop can still apply cleanly despite significant code drift in the interrem, I could see that as a real motivating factor. Matthew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
Matthew T. O'Connor [EMAIL PROTECTED] writes: I would guess that better merging might be a real motivation for people. If a patch that takes a month to develop can still apply cleanly despite significant code drift in the interrem, I could see that as a real motivating factor. Not here. You want me to trust some bit of code (with absolutely zero understanding of the source text it's hacking on) to figure out how to resolve conflicting patches? That sounds like a recipe for big-time unhappiness. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 24, 2004, at 20:29, Tom Lane wrote: Not here. You want me to trust some bit of code (with absolutely zero understanding of the source text it's hacking on) to figure out how to resolve conflicting patches? That sounds like a recipe for big-time unhappiness. The idea is that it's the responsibility of the branch owner to keep it up-to-date. For example, I've got a branch of tla (an arch implementation) I made soon after I started using it in order to add a command I wanted and refactor a bit of the insides. Over time, a lot of stuff has changed, but I still want my stuff to work, so as I update my branch against head of line, I make minor changes to it as things go. The difference is that instead of having a patch sitting in a queue somewhere suffering from bit-rot, you've got a pointer to a branch that you can merge when you get around to it. You can still view it as a diff if you want, but the diff you get six months after the original submission may be quite a bit different from what you would've got at the beginning if a lot of the code around it has changed. It's definitely not a magic tool that makes bad code good and conflicting patches happy. It solves other problems, though. Many of the problems you don't realize you have until you go back to something else and try to do something simple like undo all of the changes you've made since your last checkin. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings [EMAIL PROTECTED] |Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L___ I hope the answer won't upset her. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
