Max, On Wed, Jul 30, 2008 at 9:38 PM, Max Battcher <[EMAIL PROTECTED]> wrote: > Patrick Waugh wrote: >> >> Shouldn't this really be called the [darcs-developers] list? > > There was a merge a short while back of the two lists due to low traffic on > the darcs-users list at the time.
Gee, I wonder why? Actually, I don't wonder, but you guys should. Perhaps this email will give you some clues. >> One thing I think would be very helpful to people trying to learn to >> use darcs is example work flows. > > Some of that already exists in the darcs manual and on the darcs wiki, > perhaps you should spend a bit more time reading through both of them. But > someone could probably write an entire book on the subject or Darcs-based > workflows (and there was at least one Wikibooks attempt to do just that). Here is a great example of you and your groups reification of your fixed ideas, and inability to understand that for darcs to be successful, it has to be accessible by the masses, not just darcs developers that have intimate knowledge. Try to see darcs from a beginners mind, perhaps someone who has never ventured to try CVS, or SVN. Why? Because darcs one great (unrecognized strength) is that is appears accessible to the beginner in source control! But, when you make arrogant assumptions, like the above, you can kiss none darcs developers goodbye. For your infomation, we read the web site from stem to stern several times, and "some of that information" is not adequate. Hence my post. So, if you want to live in denial to protect your ego, fine, but it is a fact coming from the source. >> Moreover, the flow is different. It would be really helpful for >> example to show how one creates a "master" respository, then >> pulls/pushes to your working repos. And, then how one might actually >> create a "branch". > > Part of the fun of a distributed VCS like Darcs is that there are several > possible flows... There's no one "perfect setup", and instead several > workflows with various amounts of suitability dependent upon your project > and your team's needs. See here again, your assumptions get you into trouble. I'm President & COO of corporation. While I'm glad that we can "have fun" using our tools, We are not in it for the "fun". We want to get real work done, and hence need to develop a "best practice", and policy on how we are going to do it. In other words, the flexibility is great, but it creates so many possibilities for the new user that there needs to be information on "best practices" for a few common case studies to get people aware of the possibilities. Again, when we saw darcs and made the initial decision to go with it, it was because it appeared like the learning curve would be less than SVN, and it would offer more capability. > For instance, you don't need a "master" repository to use darcs. Instead you > might make every developer's repository group-readable (via a lightweight > HTTP server on each dev machine, perhaps, or existing samba shares) and > follow a "pull" mentality where each developer pulls from every other > developer as features are written. You can even do that without fully > sharing every repository using what are called "darcs context files", which > you can find more about in the Wiki or if you google it you will find an > article I wrote on the subject... While this is finally some "meat" to the question, you tell us about something that is totally unusable to us as we are developing on XP. Yes, it will do many things, but only if you have some idea HOW. Again, don't assume everyone is an expert. >> We had hoped to keep our "master" repos on our shared web server which >> is backed up for us etc. However, we don't want to have to ftp into >> the site everytime to copy up the repos. So, we looked at the add-on >> darcs-server (which I realize isn't your project), but we have been >> unable to get it to work with either version of darcs, and the author >> is unreachable by the email on his site. > > Depending on what you are doing with said "master" repositories, you don't > need anything complicated like darcs-server, either. You could have your > shared web server updated automatically from a "real master" using an > rsync/ftp in a darcs apply posthook or a cron job, as just two common > options. You could accept patches into your "real master" from email rather > than HTTP if you can't get darcs on the shared web server, but can setup a > simple email account for a harder to get to "master server". Most patches > to darcs itself are sent by email. Again, you assume we are running a *nix server, and apparently didn't read my email. Anyway, given the lack of available info, the performance issues we keep hearing about, and lack of critical mass due to Haskell at this time, I've decided we're going with hg, since it is a more mature project and can do what we need to do so we can get back to the business of creating product and stop playing with tool development. When your job is to build a space ship, you want to use the screw driver, not get bogged down in it's development. If you come up with an idea for a new one you need, you get your tool manufacturer to make one for you, so you can keep building your space ship. patrick _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
