Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
Peter Verswyvelen bugf...@gmail.com writes: I don't think it is realistic to expect that for a project of medium to large size that you work only with stable versions of modules (this would exclude most packages on Hackage I guess). I think you're putting too much into stable here. IMO, anything put on Hackage is a release with its own, unique version number, and that qualifies it for use. You could conceivably have a patch-vs-patch granularity on the dependencies, but I really don't want to go there - infinite complexity with - as far as I can tell - no tangible benefit. If those aforementioned dependency projects are just some modules within your big projects, I think the way to go is actually make them in the same repository. Yep, that's the way it's usually done. But when you have multiple teams working on different modules within the same repository, this gets annoying. If you have multiple teams working independently, they should work with defined (and versioned) interfaces, produce separate packages, and use cabal to deal with the dependencies. If your teams need to poke around in each others code to work out the dependencies, you really only have a one-team project where one half of your team doesn't get to talk enough to the other half. Currently it mostly is a management issue, and so it often goes wrong :) The developers should actually agree upon a proper set of API's before you guys actually start building the modules separately. In an idealized world I agree, but with modern agile software development methodologies, these APIs also evolve... ..and get released, versioned, and made ready for import by the rest of the world. To me, any version control system should be able to track dependencies between repositories. Something similar like Cabal's dependency system. Do one thing, and do it well. File versioning and change history: darcs. Dependency tracking and building: cabal. (What if one of the teams decides to switch to a different VCS?) Can you provide some examples of RCS that have such kind of dependency system? I'm more curious how and when it is necessary. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
On 29 Mar 2009, at 22:26, Xiao-Yong Jin wrote: Peter Verswyvelen bugf...@gmail.com writes: Mmm, my email was indeed very unclear about my question. A very simple example: suppose a development team is working on a program. This program consist of modules A and B. Each module has it's own Darcs repository. Module A requires B. When a new developer wants to get the source code, he does a darcs get server://program/A, which gives him only the latest version of A. So he manually needs to do darcs get server://program/ B (that B is required is usually discovered after a compilation error, talking to other developers to find out what the dependencies are, or by reading the cabal file). Furthermore it is unclear which version of A required which version of B (so you can't really roll back to old versions). Now assume you don't have 2 modules but dozens... I can't imagine such kind of situation, unless you are really working on a very big project. Really? To me it's almost the way darcs is *meant* to work. Both darcs and cabal work well when you work with micropackages, not one monolithic thing. What Peter is suggesting would make darcs hugely better for dealing with lots of micropackages at the same time that all go together to form a project. If those aforementioned dependency projects are just some modules within your big projects, I think the way to go is actually make them in the same repository. Really? Why should we make a monolithic blob out of what are really completely separate things that can be reused in completely separate places? I can't see the benefit of splitting those small modules to different repositories, apart from not letting other people know your current developing code. As above – they're different packages, that do something different, and can be used in many different places. It's pure coincidence that those packages were first needed for this particular project. So my point of view is that it is a management issue rather than a issue of revision control system. The developers should actually agree upon a proper set of API's before you guys actually start building the modules separately. I don't agree. If it were stable APIs developed by someone else, then yes, it would make sense, but with packages that are built side-by- side with the rest of the project, but are logically distinct, it makes very little sense. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
On Mon, Mar 30, 2009 at 8:33 AM, Ketil Malde ke...@malde.org wrote: Do one thing, and do it well. File versioning and change history: darcs. Dependency tracking and building: cabal. Yes, that could actually work. I would just need some link between a cabal version and Darcs version (I must say I don't fully grok yet how Darcs works - my mind is still in Mercurial Bazaar land - so Darcs version might not mean anything) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
Mmm, my email was indeed very unclear about my question. A very simple example: suppose a development team is working on a program. This program consist of modules A and B. Each module has it's own Darcs repository. Module A requires B. When a new developer wants to get the source code, he does a darcs get server://program/A, which gives him only the latest version of A. So he manually needs to do darcs get server://program/B (that B is required is usually discovered after a compilation error, talking to other developers to find out what the dependencies are, or by reading the cabal file). Furthermore it is unclear which version of A required which version of B (so you can't really roll back to old versions). Now assume you don't have 2 modules but dozens... To me, any version control system should be able to track dependencies between repositories. Something similar like Cabal's dependency system. So my question is really, how do you solve the dependency tracking between several Darcs repositories? (maybe I should email this to the darcs mailing list...) On Sat, Mar 28, 2009 at 4:54 AM, Simon Michael si...@joyful.com wrote: I assume cabal install darcs isn't what you're looking for.. can you give a real-world example ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
Peter Verswyvelen bugf...@gmail.com wrote: To me, any version control system should be able to track dependencies between repositories. Something similar like Cabal's dependency system. So my question is really, how do you solve the dependency tracking between several Darcs repositories? Shouldn't this be done by cabal, not darcs? i.e. cabal update querying a list of repositories for info about available versions (think standardised tags): cabal install can then figure out what to pull. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
On Sun, 29 Mar 2009, Peter Verswyvelen wrote: Module A requires B. When a new developer wants to get the source code, he does a darcs get server://program/A, which gives him only the latest version of A. So he manually needs to do darcs get server://program/B (that B is required is usually discovered after a compilation error, talking to other developers to find out what the dependencies are, or by reading the cabal file). Furthermore it is unclear which version of A required which version of B (so you can't really roll back to old versions). Now assume you don't have 2 modules but dozens... To me, any version control system should be able to track dependencies between repositories. Something similar like Cabal's dependency system. So my question is really, how do you solve the dependency tracking between several Darcs repositories? There's an (unimplemented) proposal by David Roundy for darcs sub-repos that would solve this problem: you have a darcs patch type that means depend on this patch from this other darcs repo which will be checked out in a given subdirectory. I think that solves precisely the problem you describe, and I think it should be implemented :-) Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
On Sun, Mar 29, 2009 at 10:04 PM, Ganesh Sittampalam gan...@earth.liwrote: There's an (unimplemented) proposal by David Roundy for darcs sub-repos that would solve this problem: you have a darcs patch type that means depend on this patch from this other darcs repo which will be checked out in a given subdirectory. I think that solves precisely the problem you describe, and I think it should be implemented :-) Yep, that sounds really good. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
Peter Verswyvelen bugf...@gmail.com writes: Mmm, my email was indeed very unclear about my question. A very simple example: suppose a development team is working on a program. This program consist of modules A and B. Each module has it's own Darcs repository. Module A requires B. When a new developer wants to get the source code, he does a darcs get server://program/A, which gives him only the latest version of A. So he manually needs to do darcs get server://program/B (that B is required is usually discovered after a compilation error, talking to other developers to find out what the dependencies are, or by reading the cabal file). Furthermore it is unclear which version of A required which version of B (so you can't really roll back to old versions). Now assume you don't have 2 modules but dozens... I can't imagine such kind of situation, unless you are really working on a very big project. Usually, if your project depends on other projects, mostly it should work with stable version of other projects, but not their develop version. You might need some features of other projects that is still under development, than you might have a few repositories. However, such situation should be well known across all developers of your project. And usually you guys should agree on one particular develop version of those dependency projects, to make sure that you guys are working with the same set of API's. If those aforementioned dependency projects are just some modules within your big projects, I think the way to go is actually make them in the same repository. I can't see the benefit of splitting those small modules to different repositories, apart from not letting other people know your current developing code. But we are using a distributed revision control system, as darcs is, you can choose which patch to push to the upper stream anyway. So my point of view is that it is a management issue rather than a issue of revision control system. The developers should actually agree upon a proper set of API's before you guys actually start building the modules separately. Another reason for such kind of RCS built-in dependency check being impossible is that darcs are basically dealing with a bunch of dependent patches. Those patches only know their dependencies within a particular repository. You can't logically put a dependency of an external repository before you start pulling from that repository. To me, any version control system should be able to track dependencies between repositories. Something similar like Cabal's dependency system. Can you provide some examples of RCS that have such kind of dependency system? So my question is really, how do you solve the dependency tracking between several Darcs repositories? Because every source tree is a branch in darcs, you can't. -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
On 2009 Mar 29, at 16:26, Xiao-Yong Jin wrote: Peter Verswyvelen bugf...@gmail.com writes: Module A requires B. When a new developer wants to get the source code, he does a darcs get server://program/A, which gives him only the latest version of A. So he manually needs to do darcs get server://program/ B (that B is required is usually discovered after a compilation error, talking to other developers to find out what the dependencies are, or by reading the cabal file). Furthermore it is unclear which version of A required which version of B (so you can't really roll back to old versions). Now assume you don't have 2 modules but dozens... I can't imagine such kind of situation, unless you are really working on a very big project. Usually, if your Ever looked at ghc's source? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
On Sun, Mar 29, 2009 at 10:26 PM, Xiao-Yong Jin xj2...@columbia.edu wrote: Now assume you don't have 2 modules but dozens... I can't imagine such kind of situation, unless you are really working on a very big project. Usually, if your project depends on other projects, mostly it should work with stable version of other projects, but not their develop version. You might need some features of other projects that is still under development, than you might have a few repositories. However, such situation should be well known across all developers of your project. And usually you guys should agree on one particular develop version of those dependency projects, to make sure that you guys are working with the same set of API's. Even if you have just two modules, manually keeping track which version used which other version feels error prone. And you need that when you want to revert to old versions (which I heard is very hard to do with Darcs anyway, but I can't confirm that, haven't tried it yet) I don't think it is realistic to expect that for a project of medium to large size that you work only with stable versions of modules (this would exclude most packages on Hackage I guess). I understand this is the way it *should* be, but I don't think it often does. I prefer to use some unstable packages from Hackage, and contribute bugfixes or even enhancements to these packages. If those aforementioned dependency projects are just some modules within your big projects, I think the way to go is actually make them in the same repository. Yep, that's the way it's usually done. But when you have multiple teams working on different modules within the same repository, this gets annoying. I can't see the benefit of splitting those small modules to different repositories, apart from not letting other people know your current developing code. But we are using a distributed revision control system, as darcs is, you can choose which patch to push to the upper stream anyway. So my point of view is that it is a management issue rather than a issue of revision control system. Currently it mostly is a management issue, and so it often goes wrong :) The developers should actually agree upon a proper set of API's before you guys actually start building the modules separately. In an idealized world I agree, but with modern agile software development methodologies, these APIs also evolve... Another reason for such kind of RCS built-in dependency check being impossible is that darcs are basically dealing with a bunch of dependent patches. Those patches only know their dependencies within a particular repository. You can't logically put a dependency of an external repository before you start pulling from that repository. Sure, but that sounds like a current limitation, doesn't seem like this is impossible to extend. To me, any version control system should be able to track dependencies between repositories. Something similar like Cabal's dependency system. Can you provide some examples of RCS that have such kind of dependency system? Mercurial had an extensionhttp://www.selenic.com/mercurial/wiki/index.cgi/ForestExtensionfor this. I'm not sure but maybe ClearCase and Accurev also support something like. A couple of years ago I also developed a version control system (closed source, private solution for customer, NTFS only) that supported dependencies between repositories ( too bad that company did not want to release the software as open source :| ) So my question is really, how do you solve the dependency tracking between several Darcs repositories? Because every source tree is a branch in darcs, you can't. Too bad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
I assume cabal install darcs isn't what you're looking for.. can you give a real-world example ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
