Re: [fossil-users] Add files recursively?
I think that fossil solution of using a simple file __FOSSIL__ in the root directory is a far superior solution than the classical of creating a directory for the SCM. The only point is that files manifest and manifest.uuid should not be there by default in new projects. Only people actively interested in them for automating tasks should request actively to fossil to maintain them. NOTE: the fossil repository file needs not to be located in the same directory. You can put in anywhere. In fact, I consider a better solution to put all fossil repositories in a dedicated unique directory, to have better control of backups, and of data integrity. Of course, this is personal taste. RR 2010/1/21 Daniel Carrera dcarr...@gmail.com: Paul Serice wrote: __FOSSIL__ is required, though you can rename it to .fos if you don't want to look at it. This is dangerous because the following commands do very bad things: fossil extras --dotfiles fossil clean -f --dotfiles Then it is a mis-feature (or bug) that you can turn __FOSSIL__ into .fos (or that there are --dotfiles options). I don't understand why Fossil has to put four files in my root directory (myproj.fossil, __FOSSIL__, manifest, manifest.uuid). Why can't it have a single directory like _fossil/ just like every other decent SCM today? That directory should include the two database files (so I don't have to wonder why you need *TWO* database files -- I thought you were supposed to have only one) and it should include the manifest files (so that Michael can use them in his project bills without Daniel getting annoyed that they keep polluting his root directory). Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Ramon Ribó wrote: I think that fossil solution of using a simple file __FOSSIL__ in the root directory is a far superior solution than the classical of creating a directory for the SCM. Why? Even if you get rid of manifest and manifest.uuid you still have two files. Why not put them together in a directory? Also, if you do want manifest and manifest.uuid why should you have to put up with a more polluted root directory? Again, put them in a directory. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
No. You would have ONE file: __FOSSIL__. Much better than having a directory plenty of files. I insist that the repository file needs not to be in the same directory tree than the project files. The beautiful thing about fossil is that: - The fossil package is a simple executable file, with no dependencies - The repository is just one file (easy to backup, move, etc) - The control file in the files hierarchy will be just one file (once we get rid of manifest and manifest.uuid) - The web server is just one file (the CGI script) Don't you like simplicity?. For people that consider simplicity a boring thing, there are probably alternatives to fossil like git, mercurial, etc. that will give the user more options than the ones that he can learn in one entire life. All uf us must thank DRH for transferring his experience on sqlite and its simplicity into a SCM system like fossil. RR 2010/1/21 Daniel Carrera dcarr...@gmail.com: Ramon Ribó wrote: I think that fossil solution of using a simple file __FOSSIL__ in the root directory is a far superior solution than the classical of creating a directory for the SCM. Why? Even if you get rid of manifest and manifest.uuid you still have two files. Why not put them together in a directory? Also, if you do want manifest and manifest.uuid why should you have to put up with a more polluted root directory? Again, put them in a directory. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Ramon Ribó wrote: No. You would have ONE file: __FOSSIL__. Much better than having a directory plenty of files. I insist that the repository file needs not to be in the same directory tree than the project files. 1) I don't see how one file is better than one directory with one file. 2) But the truth is that there *are* other files. You can move them to other directories, but they still exist, and arguably it is worse to have the other files spread out instead of having them together. If you are going to have N files, and N 1, it makes sense to put those N files in one directory. Spreading the files around does not solve the problem. Arguably it could create new problems. The beautiful thing about fossil is that: - The fossil package is a simple executable file, with no dependencies - The repository is just one file (easy to backup, move, etc) No objection here. - The control file in the files hierarchy will be just one file (once we get rid of manifest and manifest.uuid) Notice the disclaimer: It will do this once we change this other thing. Don't you like simplicity?. Which is more simple: a) Put the files in one directory. b) Change a configuration to get rid of two files, then move one of the remaining files to some other place and configure fossil to look at that other place to find the repository. As a new user, so far I am *NOT* finding fossil simple. For example, my experience trying to setup a server and pulling from it has been less than stellar. I began looking into fossil because I wanted a *simple* and *easy* SCM that I could give to people who are not experienced with SCMs. My boss asked me to find a solution to let people contribute to small developing projects. Many of these are students, others are school teachers who taught themselves basic programming skills. The idea is to have a place for them to put their code, without creating a lot of complexity or difficulty for them. I began looking at fossil because it claimed to be simple and easy (plus I liked the incorporated wiki and bug tracker). After evaluating it for a few days, I am leaning to think that fossil is *not* that simple and that it is *not* suitable for beginners who don't have a lot of patience or knowledge. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
On Thursday 21 January 2010 11:46:23 Daniel Carrera wrote: As a new user, so far I am *NOT* finding fossil simple. For example, my experience trying to setup a server and pulling from it has been less than stellar. ... a few days, I am leaning to think that fossil is *not* that simple and that it is *not* suitable for beginners who don't have a lot of patience or knowledge. If you have ever used svn or git, you will understand just how easy fossil is by comparison. It is up to you as the sysadmin to set things up so they are easy for the less experienced users. It may be that something like svn is more suited to your users (though as sysadmin, you will not be happy). I am currently evaluating whether migrating my current users (at work) to Fossil is worth the extra time I will have to spend educating them. Certainly from a sysadmin standpoint, Fossil is much better. If there were an svn-to-fossil conversion utility, I would probably go for it right away. I've already switched over for my personal projects. No source-control system is easier to use than Fossil, in my experience. Certainly not one which allows for decentralized development. However, the concepts need to be understood before diving in. As Michael pointed out, your mileage may vary... -- For privacy, my GPG key signature is: AD29415D signature.asc Description: This is a digitally signed message part. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Michael Richter wrote: 1) I don't see how one file is better than one directory with one file. One is two entities to keep track of (one directory, one file) and one is a single entity to keep track of (one file). Seems pretty obvious to me. You won't be surprised to hear that I differ. When I use darcs I don't think about which files are inside '_darcs/' but fossil forces me to think about four files and pollutes my root directory. 2) But the truth is that there *are* other files. You can move them to other directories, but they still exist, and arguably it is worse to have the other files spread out instead of having them together. You are not understanding the whole point of this. *You are not _intended_ to put your repository file in the same directory as your project.* The repository is a single database which is shared by all checked-out instances of it. Ok, but (1) this is not in the docs and (2) it doesn't solve the more files to keep track of issue. Other SCMs manage to work without asking me to have a separate file in some directory outside my directory tree. It seems odd that fossil would need to add that extra little bit of complexity. Consider the case of hg or darcs or some other such distributed system which conflates the repository and the working set. I'm working on a project, so I clone a remote repository into a local directory. I make changes to feature A. While I'm working on A, I get a high-priority request to work on feature B. Either I clone the remote repository again (needs network, needs time, hits the remote server harder in a large project, wastes space as the repository itself is recopied, etc.) or I clone my local copy in A (which just wastes the space). If don't see how fossil makes you waste a lot less space. You still have two working trees. You avoid duplicating the database, but I would assume that that's not a very large file to begin with. Especially on modern hard disks. I have a Darcs project that has been going on for a while. The _darcs directory is 13MB and my hard disk has space for 160GB. It never crossed my mind to think about wasting 0.008% of my hard disk. I can get back a lot more space by removing a program I don't use. Let's say we took the second option. While I'm working in B, I finish my work in A. I push my changes and delete A ... and WHOOPS! I just screwed up B, didn't I? Why would that screw up B? If making a little branch like that screws up the SCM then the SCM sucks. The whole reasons why we have SCMs so to allow concurrent development. B is expecting A as an uplink which is now gone because the distinction between the working set and the repository is fuzzy. If your SCM works like that, then it's the SCM's fault. It's stupid. Take Darcs, Mercurial or Bazaar. Create a repository, then pull from it to make A, then pull from that to make B, then delete A, and there is no problem. Why would there be? A is a branch, B is a branch, there is no good reason why B needs A. I can reseat B to point to another copy of the repository (and hope that that repository doesnt' have changes which clash with the changes I made in A and in B) but I think anybody can see that this is not a particularly good solution. I think it is fixing the wrong problem. B should not have to point to one specific branch for it to work. If this is how fossil works, to me that's just one more reason not to use fossil. As I said, the whole point of SCMs is to allow concurrent development and this is more true for distributed SCMs. I should be able to make branches nilly willy without the whole thing breaking due to some weird DAG that the SCM needs. I don't have to think about these things if I use Darcs, Bazaar or Mercurial. Fossil keeps the concept of the repository and the working set distinct. Btw, AFAIK the only SCM that joins these concepts is Darcs. Anyways, the things you've said have only scared me off from using fossil. I didn't know that fossil would require branches to point to other branches in some sort of DAG. b) Change a configuration to get rid of two files, then move one of the remaining files to some other place and configure fossil to look at that other place to find the repository. You are really not understanding the difference between a repository and a working set. You need to understand this before you make anymore asinine statements. I am familiar with the distinction, thanks. That doesn't mean I agree with fossil's way of doing things. It's still asking me to keep track of more files than other SCMs which also distinguish between working set and repository. On behalf of the Fossil community I apologize for Fossil not suiting your needs. Perhaps you'd prefer Mercurial (hg), Darcs, Bazaar, Monotone, SVK or Git? Or perhaps even CVS or SVN or some other centralized SCM? If you're
Re: [fossil-users] Add files recursively?
Ron Aaron wrote: If you have ever used svn or git, you will understand just how easy fossil is by comparison. Thankfully I haven't had to use SVN or Git. Well, I did have to admin SVN + Trac for a while and I hated it. But as a developer, my experience is mostly from Darcs. I'm also familiar with Mercurial and Bazaar. I've had to use CVS before and I would never choose it for a project. The thought of using CVS would never cross my mind. It is up to you as the sysadmin to set things up so they are easy for the less experienced users. It may be that something like svn is more suited to your users (though as sysadmin, you will not be happy). One of my goals is to make my life easy :-) I hate doing sysadmin work. I want to make account management easy. Otherwise I'll spend my whole time doing sysadmin work instead of developing software which is what I'm actually paid to do. I am currently evaluating whether migrating my current users (at work) to Fossil is worth the extra time I will have to spend educating them. Certainly from a sysadmin standpoint, Fossil is much better. If there were an svn-to-fossil conversion utility, I would probably go for it right away. I've already switched over for my personal projects. Thankfully I don't have to worry about migration. This is a Green Field thing. The problem I have is that we are talking about users who are not mainly developers. I have two groups of people: Senior high school students who are learning how to program, and some teachers who learned how to program. My boss wants to have a place on our website where they can upload their work. Currently we just have a CMS (Drupal) where people can make accounts and click on upload file. But we might need something better in the long run. My boss wants to just have a public FTP account where anyone can upload stuff. I think that's crazy. Might as well put a sign that says Crackers welcome, please exploit our server. So I'm looking for something to help newbie programmers manage software projects without creating a lot of admin work for me, and without opening a huge security hole for our company. No source-control system is easier to use than Fossil, in my experience. Certainly not one which allows for decentralized development. However, the concepts need to be understood before diving in. As Michael pointed out, your mileage may vary... Even if that is the case: That Fossil is easier in the long run but requires more initial learning than other SCMs, that would indicate that Fossil is not the right choice for me. I want something that new users can learn quickly. In principle I like Darcs, Bazaar and Mercurial, but they don't have the wiki or bug tracking that fossil has, and at least some of them would require me to give SSH access to the users. So they are completely unsuitable for what I need to do. It might be that there isn't any software at all that does what I want. That would be a real shame. Maybe I'm wrong to be looking at SCMs at all. Maybe I should be looking at something like Trac... But I've setup track before and I *know* I don't want to set it up again. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Wait... read this: C:\md repo C:\cd repo C:\repofossil new actual.fossil blah... C:\repocd .. C:\md waA C:\cd waA C:\waAfossil open ..\repo\actual.fossil C:\waAcd .. C:\md waB C:\cd waB C:\waBfossil open ..\repo\actual.fossil C:\waBcd .. C:\ There are only three files in waA and waB, which will come down to 1 when DRH commits the change. waA and waB are not related at all, other than the fact that they share (push/pull) same repository (C:\repo\actual.fossil). ... and, fossil server c:\repo\actual.fossil will give you a working fossil server! Try fossil ui c:\repo\actual.fossil if that makes it easy. - Altu -Original Message- From: Daniel Carrera dcarr...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Jan 21, 2010 4:13 pm Subject: Re: [fossil-users] Add files recursively? Michael Richter wrote: 1) I don't see how one file is better than one directory with one file. One is two entities to keep track of (one directory, one file) and one is a single entity to keep track of (one file). Seems pretty obvious to me.You won't be surprised to hear that I differ. When I use darcs I don't think about which files are inside '_darcs/' but fossil forces me to think about four files and pollutes my root directory. 2) But the truth is that there *are* other files. You can move them to other directories, but they still exist, and arguably it is worse to have the other files spread out instead of having them together. You are not understanding the whole point of this. *You are not _intended_ to put your repository file in the same directory as your project.* The repository is a single database which is shared by all checked-out instances of it.Ok, but (1) this is not in the docs and (2) it doesn't solve the more files to keep track of issue. Other SCMs manage to work without asking me to have a separate file in some directory outside my directory tree. It seems odd that fossil would need to add that extra little bit of complexity. Consider the case of hg or darcs or some other such distributed system which conflates the repository and the working set. I'm working on a project, so I clone a remote repository into a local directory. I make changes to feature A. While I'm working on A, I get a high-priority request to work on feature B. Either I clone the remote repository again (needs network, needs time, hits the remote server harder in a large project, wastes space as the repository itself is recopied, etc.) or I clone my local copy in A (which just wastes the space).If don't see how fossil makes you waste a lot less space. You still have two working trees. You avoid duplicating the database, but I would assume that that's not a very large file to begin with. Especially on modern hard disks. I have a Darcs project that has been going on for a while. The _darcs directory is 13MB and my hard disk has space for 160GB. It never crossed my mind to think about wasting 0.008% of my hard disk. I can get back a lot more space by removing a program I don't use. Let's say we took the second option. While I'm working in B, I finish my work in A. I push my changes and delete A ... and WHOOPS! I just screwed up B, didn't I?Why would that screw up B? If making a little branch like that screws up the SCM then the SCM sucks. The whole reasons why we have SCMs so to allow concurrent development. B is expecting A as an uplink which is now gone because the distinction between the working set and the repository is fuzzy.If your SCM works like that, then it's the SCM's fault. It's stupid. Take Darcs, Mercurial or Bazaar. Create a repository, then pull from it to make A, then pull from that to make B, then delete A, and there is no problem. Why would there be? A is a branch, B is a branch, there is no good reason why B needs A. I can reseat B to point to another copy of the repository (and hope that that repository doesnt' have changes which clash with the changes I made in A and in B) but I think anybody can see that this is not a particularly good solution.I think it is fixing the wrong problem. B should not have to point to one specific branch for it to work. If this is how fossil works, to me that's just one more reason not to use fossil. As I said, the whole point of SCMs is to allow concurrent development and this is more true for distributed SCMs. I should be able to make branches nilly willy without the whole thing breaking due to some weird DAG that the SCM needs. I don't have to think about these things if I use Darcs, Bazaar or Mercurial. Fossil keeps the concept of the repository and the working set distinct.Btw, AFAIK the only SCM that joins these concepts is Darcs.Anyways, the things you've said have only scared me off from using fossil. I didn't know that fossil would require branches to point to other branches in some sort of DAG. b) Change a configuration to get rid of two files
Re: [fossil-users] Add files recursively?
Twylite wrote: Then use Visual SourceSafe, or Subversion. They are simple to understand: a network filesystem with an added dimension for time (revisions). I googled for SourceSafe. Looks like it's a proprietary MS product. :( I already know I don't want SVN. I had to admin it once, and I'll never do it again. With any DVCS users must understand the distinction between a repository and a working set, and they must understand branching and merging. You can use Darcs, Mercurial and Bazaar in a simple project without having to go deeply into repository vs working set. And you only have to deal with branching and merging if you actually have a team of users. Obtaining the files changes from get (or checkout or update, depending on your VCS) to clone, open or pull, update. Committing a change changes from commit (or checkin) to commit, push. The extra steps are not obvious to users who don't understand the DVCS paradigm, and can be very confusing (I committed it, why can't he see it? Oh, you committed it but you didn't push it ?!?). I could be wrong, since I've been using DVCS for several years, but it doesn't look complicated to me. I'd tell them that commit saves your work and push uploads them to the server. But as I said, my perspective might be affected by the fact that I already know these concepts. Things always look easier when you already understand them. You also need to have all your projects in one repository, or one repository per project. Unlike a centralised VCS, partial (subtree) checkouts are not possible. This isn't something users have to think about. I was planning to go for one repository per project as an easy way to get access control and not have people trampling on each other's work. So the former option just means extra traffic and storing for someone working on a single project; the latter means extra working if you need to sync and work on multiple projects. No syncing. In my mind, if it's another project, it's unrelated. Furthermore the granularity of access control is at repository level (you either have access to the entire contents of a repository, or to no contents of the repository). Yes. That's why I had in mind one project, one repository. Since I'm not a beginner I can't comment on that ;p On the other hand I don't have a lot of patience. When I started with Fossil a few months back, it was after evaluating (read: install on my PC, play with, install on a server, play more) bazaar and hg. Fossil was significantly easier to use both locally and to get working on a server (I would use the word trivial for server installation, quite unlike bazaar/hg). I have not tried to install bazaar or hg on the server. You might be right. One of the things I was looking for with fossil is easier server management. For example, I might think that Darcs is extremely easy to use, but I'd have to give people SSH access to the server and I don't want to deal with that can of worms. I was attracted by the idea of using a CGI script, so I can give people access to *just* the SCM. When you clone A to B, a note is made in B that you cloned from A. So when you are working in B and you push or pull or sync it knows that the endpoint of that operation is A. I think that's bad. Darcs doesn't do that, and I would venture to guess that Bazaar and Mercurial don't either. Branches should be equal and independent. That sequence applies to Fossil, Git, Hg, Bazaar, and DVCS in general. I can't comment about Git. I don't think this is true for Hg or Bazaar. I can guarantee it is not true for Darcs. As I said, branches should be equal and independent. Inter-branch dependencies seems like the opposite of decentralization. It also leads to some WTF behaviour. For example, you make a change to A, commit, push. Then you make a change to B, commit, push. Then you delete both A and B because you've finished and pushed the changes. Indeed. If my SCM did that I'd be furious. Did you notice that you lost the changes you made in B? Because you pushed them to A, not to REMOTE? That happens a lot with new users of git, bazaar and hg, because each working set on your PC has an attached repository. With Fossil there is one local repository with multiple local working sets, so you don't have this problem. I have *never* heard of something like this happening. Maybe I'm too stuck with Darcs, but I'm a bit shocked to hear that Hg or Bazaar have inter-branch dependencies like you suggest. I think I might go to the Hg or Bazaar mailing list and verify this. It doesn't sound right at all. Fossil keeps the concept of the repository and the working set distinct. Btw, AFAIK the only SCM that joins these concepts is Darcs. Wrong. Git, Hg and (depending on your workflow) Bazaar all keep a repository clone local to the working set. In the same directory, but pulling from another branch
Re: [fossil-users] Add files recursively?
Hi Twlite, Wait... I just re-read your post. Tell me if I'm right. Your whole beef with other SCMs is that you have to type: myscm push http://some-repository.org Is that the issue that you and Michael are talking about? That you have to specify the URL of the place you are pushing to the first time you push? That seems hardly like a major issue for other SCMs, and it doesn't seem like fossil can do much to avoid this. I imagine that with fossil you still have to tell it where you want to push to the first time you push there. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
2010/1/21 Daniel Carrera dcarr...@gmail.com When you clone A to B, a note is made in B that you cloned from A. So when you are working in B and you push or pull or sync it knows that the endpoint of that operation is A. I think that's bad. Darcs doesn't do that, and I would venture to guess that Bazaar and Mercurial don't either. Branches should be equal and independent. Really? Watch and learn. mich...@isolde:~/junk$ mkdir A B Remote mich...@isolde:~/junk$ cd Remote mich...@isolde:~/junk/Remote$ darcs initialize mich...@isolde:~/junk/Remote$ touch 1 mich...@isolde:~/junk/Remote$ darcs add 1 ; darcs record addfile ./1 Shall I record this change? (1/1) [ynWsfvplxdaqjk], or ? for help: y What is the patch name? file 1 in Remote Do you want to add a long comment? [yn]n Finished recording patch 'file 1 in Remote' mich...@isolde:~/junk/Remote$ cd ../A mich...@isolde:~/junk/A$ darcs initialize ; darcs pull ../Remote Thu Jan 21 21:01:48 CST 2010 ttmrich...@gmail.com * file 1 in Remote Shall I pull this patch? (1/1) [ynWsfvplxdaqjk], or ? for help: a Finished pulling and applying. mich...@isolde:~/junk/A$ touch 2 mich...@isolde:~/junk/A$ darcs add 2 mich...@isolde:~/junk/A$ darcs record addfile ./2 Shall I record this change? (1/1) [ynWsfvplxdaqjk], or ? for help: a What is the patch name? file 2 in A Do you want to add a long comment? [yn]n Finished recording patch 'file 2 in A' mich...@isolde:~/junk/A$ cd ../B mich...@isolde:~/junk/B$ darcs initialize mich...@isolde:~/junk/B$ darcs pull ../A Thu Jan 21 21:01:48 CST 2010 ttmrich...@gmail.com * file 1 in Remote Shall I pull this patch? (1/2) [ynWsfvplxdaqjk], or ? for help: a Finished pulling and applying. mich...@isolde:~/junk/B$ touch 3 mich...@isolde:~/junk/B$ darcs add 3 mich...@isolde:~/junk/B$ darcs record addfile ./3 Shall I record this change? (1/1) [ynWsfvplxdaqjk], or ? for help: a What is the patch name? file 3 in B Do you want to add a long comment? [yn]n Finished recording patch 'file 3 in B' The stage is now set. We have a remote repository. We have a local repository A taken from the remote one that has added some stuff. We have a local repository B taken from A that has added some stuff. Now watch: mich...@isolde:~/junk/B$ cd .. mich...@isolde:~/junk$ rm -fR A removed `A/1' removed `A/_darcs/tentative_pristine' removed `A/_darcs/patches/000115-3cd043376a21c461f8605abb2a579f58ff2419e37248c357425a3a143a9d6ecb' removed `A/_darcs/patches/pending' removed `A/_darcs/patches/000110-b044ffccac260b63c9f0f4d92b1c5b85e4221128a9ddf37c12a36415a8d2bdd4' removed `A/_darcs/patches/pending.tentative' removed directory: `A/_darcs/patches' removed `A/_darcs/inventories/000187-198d8c81582fe412f44f446a65a8e40b3b1267107a3e6e72ad2b50a27dbd67e9' removed `A/_darcs/inventories/000369-511de1bfebfc9e3803f8c9d12aef84bf5312f03b013eb16c07709fc8b67ba625' removed directory: `A/_darcs/inventories' removed `A/_darcs/format' removed `A/_darcs/prefs/repos' removed `A/_darcs/prefs/boring' removed `A/_darcs/prefs/author' removed `A/_darcs/prefs/binaries' removed `A/_darcs/prefs/motd' removed `A/_darcs/prefs/defaultrepo' removed directory: `A/_darcs/prefs' removed `A/_darcs/hashed_inventory' removed `A/_darcs/pristine.hashed/000168-cdb7d192d528a5ab1468b5d4339004ddf47442b6bd2d2e2a6f3ba38c724c0883' removed `A/_darcs/pristine.hashed/da39a3ee5e6b4b0d3255bfef95601890afd80709' removed `A/_darcs/pristine.hashed/00-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855' removed `A/_darcs/pristine.hashed/84-555aaf4b6798d05de804c5dd6de6d1707fece5d5d1dcc9dd34c3834e55058b1e' removed directory: `A/_darcs/pristine.hashed' removed directory: `A/_darcs' removed `A/2' removed directory: `A' mich...@isolde:~/junk$ cd B mich...@isolde:~/junk/B$ darcs push darcs failed: Not a repository: /home/michael/junk/A (/home/michael/junk/A/_darcs/inventory: openBinaryFile: does not exist (No such file or directory)) Oops. So much for equal and independent branches! This is what happens when your working set and your repository are one and the same. You create chains of relationships that can *and do* (keep in mind that I have used both Mercurial and Darcs long before I found fossil) lead to lost data and difficult to debug problems. Consider this sequence instead: - I clone a remote repository to A. - Someone else clones my repository A to B. - I make my changes and push them. - The other guy makes his changes and pushes them. - I don't notice this last thing and think that I'm done with my work and delete my working set/repository. - He thinks his work is done and deletes his working set/repository. The other guy's work is now lost because of that chain of working set/repositories. In fossil the workflow is different: - I clone a remote repository to a repository file in a known location. (For my work I have them in ~/Repositories. For my shared work I have them in /var/repositories.) - I
Re: [fossil-users] Add files recursively?
Hi, Wait... I just re-read your post. Tell me if I'm right. Your whole beef with other SCMs is that you have to type: myscm push http://some-repository.org Is that the issue that you and Michael are talking about? That you have to specify the URL of the place you are pushing to the first time you push? For some value of beef, yes. I don't have to tell fossil or hg or bazaar where to push - they know it based on where I cloned from. The distinction is that in fossil I have one repository on my machine and I open multiple working sets on the same repository. When I push or pull, it is always with the parent of that one repository. In hg or bazaar I clone the repository each time I want a new working set. When I push or pull _by default_ (i.e. I don't explicitly specify the repository) it will be with the parent, which in some cases will be a REMOTE and in other cases another local repository. Always explicitly specifying the remote repository is safest because it avoids this confusion; if you don't then you have to be exceedingly careful that you understand which repository you are pushing to or pulling from. A similar problem occurs when pulling down changes (to update and merge). With fossil you have one repository and multiple working folders. So you commit in one working folder, and update in the other folders. With bazaar and hg you commit to your repository which is local to your working set, so you must push/pull the change to other working folders. Regards, Twylite ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Michael Richter wrote: mich...@isolde:~/junk/B$ darcs push darcs failed: Not a repository: /home/michael/junk/A (/home/michael/junk/A/_darcs/inventory: openBinaryFile: does not exist (No such file or directory)) Oops. So much for equal and independent branches! Ugh. Your beef is that you have to specify where you are pushing to? That hardly seems like a dependency, or like something that fossil can avoid. How does any SCM, know where I want to push when I just say push? It has to pick some reasonable default such as the place I pushed or pulled from last time. Fossil will have a default too. And if you try to push to a place that doesn't exist I'm sure Fossil will complain. That's hardly a dependency or an inequality between branches. Anyways, I copied your earlier comment and Twylite on the Bazaar mailing list. They have confirmed my views. Where does Fossil push if I just say fossil push? What if I remove that location? Will Fossil not complain? Or will it somehow know I want to push to some other place? Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Twylite wrote: I'm afraid I simply don't understand. You set it up, it runs. You make backups using a cron script or the Task Scheduler. What more is there to administrating SVN? If I recall correctly, setup was very non-trivial, and you have to give SSH keys to anyone who wants to contribute, so that's more work too. I find it that rarely does software run without any need for maintenance. When you clone A to B you have not branched anything. You have created a copy of the repository. That is all. Maybe in fossil. But you are trying to argue that there is a problem with other distributed SCMs. In those SCMs you criticize, the problem you are describing does not exist. They *are* branches in Darcs, Git, Hg and Bazaar (the Bazaar list just confirmed this). Most of these tools do support light-weight branches (Hg doesn't) but that's certainly not the default behaviour. The copy knows where it was copied from, so that it will automatically talk to the original repository when you try to push or pull. In other SCMs, every branch knows where you pushed or pulled from last time. If you push somewhere else, the next time you type push without a parameter they'll push to that other place. That alternative is that whenever you push or pull you must provide the path/URL of the other repository (which you don't need to do with git, hg, bazaar, fossil, etc. precisely because it makes this note that B is copied from A). Darcs, Hg, Bazaar and Git do nothing of the sort. They just remember where you pushed or pulled form next and save you typing. But that doesn't make the current branch a dependency on any other branch. Without making any changes to A or B, you can delete A, and then B will not be able to push/pull without you telling it where to find a new parent repository. In Darcs, Hg, Bazaar and Git, the branch A is not a parent unless you went out of your way to make a light-weight branch. I didn't even know until today that Darcs supported light-weight branches. Branching cannot happen until you actually commit a change into a repository. That's the fossil view. But if you are going to criticize other SCMs, you need to learn how they view branching. What you said is not true for other SCMs. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
2010/1/21 Daniel Carrera dcarr...@gmail.com Michael Richter wrote: mich...@isolde:~/junk/B$ darcs push darcs failed: Not a repository: /home/michael/junk/A (/home/michael/junk/A/_darcs/inventory: openBinaryFile: does not exist (No such file or directory)) Oops. So much for equal and independent branches! Ugh. Your beef is that you have to specify where you are pushing to? Do you read before you respond? My specific beef was given and it has nothing to do with specifying where I'm pushing to. (Hint: *lost work*.) That hardly seems like a dependency, or like something that fossil can avoid. How does any SCM, know where I want to push when I just say push? Because, Sparky, when you clone a repo in fossil you have a repository file. That repository file contains the original place you cloned from within it. You have to *open* said file to get your working set and the repo that your working set comes from is conveniently stored for you in _FOSSIL_ -- that file you hate so much. So when you say fossil commit, fossil knows where to commit because, get this, your working set comes from a repository and has it recorded all automagically-like. Further, when you say fossil push, fossil knows which repository you're talking about (from _FOSSIL_) and then where that repository pushes to (the repo file). That whole separation of concerns thing is what I like about Fossil and what I didn't like about Mercurial or Darcs. Where does Fossil push if I just say fossil push? What if I remove that location? Will Fossil not complain? Or will it somehow know I want to push to some other place? If you're dumb enough to remove the repository (as opposed to your working set) you've got problems of course. The difference is that it takes specific user action separate and above the deletion of the working set to delete the repository. With Darcs and Mercurial both I've accidentally turfed repositories that held data as yet un-propagated because I'd forgotten that I'd cloned them to do some work and pushed locally. I deleted what I thought was basically just a working set only to find out that I'd accidentally deleted actual work. This kind of accident doesn't happen in Fossil because I don't delete repositories unless I'm sure that, you know, I'm never working on that project again. In the case of my shared repositories I don't delete them at all unless the project itself has been canned (and even then I keep 'em around). No room for accidents. Anyway, with this I'm bowing out. You're obviously not reading the docs nor the messages of the people explaining things to you. I'll let people more patient than me educate you if you're at all capable of such. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Btw, the remote repository is completely unnecessary for your example to work. You can just make repository A, make branch B, delete A, and you'll get the same error message. Daniel. Michael Richter wrote: 2010/1/21 Daniel Carrera dcarr...@gmail.com mailto:dcarr...@gmail.com When you clone A to B, a note is made in B that you cloned from A. So when you are working in B and you push or pull or sync it knows that the endpoint of that operation is A. I think that's bad. Darcs doesn't do that, and I would venture to guess that Bazaar and Mercurial don't either. Branches should be equal and independent. Really? Watch and learn. mich...@isolde:~/junk$ mkdir A B Remote mich...@isolde:~/junk$ cd Remote mich...@isolde:~/junk/Remote$ darcs initialize mich...@isolde:~/junk/Remote$ touch 1 mich...@isolde:~/junk/Remote$ darcs add 1 ; darcs record addfile ./1 Shall I record this change? (1/1) [ynWsfvplxdaqjk], or ? for help: y What is the patch name? file 1 in Remote Do you want to add a long comment? [yn]n Finished recording patch 'file 1 in Remote' mich...@isolde:~/junk/Remote$ cd ../A mich...@isolde:~/junk/A$ darcs initialize ; darcs pull ../Remote Thu Jan 21 21:01:48 CST 2010 ttmrich...@gmail.com mailto:ttmrich...@gmail.com * file 1 in Remote Shall I pull this patch? (1/1) [ynWsfvplxdaqjk], or ? for help: a Finished pulling and applying. mich...@isolde:~/junk/A$ touch 2 mich...@isolde:~/junk/A$ darcs add 2 mich...@isolde:~/junk/A$ darcs record addfile ./2 Shall I record this change? (1/1) [ynWsfvplxdaqjk], or ? for help: a What is the patch name? file 2 in A Do you want to add a long comment? [yn]n Finished recording patch 'file 2 in A' mich...@isolde:~/junk/A$ cd ../B mich...@isolde:~/junk/B$ darcs initialize mich...@isolde:~/junk/B$ darcs pull ../A Thu Jan 21 21:01:48 CST 2010 ttmrich...@gmail.com mailto:ttmrich...@gmail.com * file 1 in Remote Shall I pull this patch? (1/2) [ynWsfvplxdaqjk], or ? for help: a Finished pulling and applying. mich...@isolde:~/junk/B$ touch 3 mich...@isolde:~/junk/B$ darcs add 3 mich...@isolde:~/junk/B$ darcs record addfile ./3 Shall I record this change? (1/1) [ynWsfvplxdaqjk], or ? for help: a What is the patch name? file 3 in B Do you want to add a long comment? [yn]n Finished recording patch 'file 3 in B' The stage is now set. We have a remote repository. We have a local repository A taken from the remote one that has added some stuff. We have a local repository B taken from A that has added some stuff. Now watch: mich...@isolde:~/junk/B$ cd .. mich...@isolde:~/junk$ rm -fR A removed `A/1' removed `A/_darcs/tentative_pristine' removed `A/_darcs/patches/000115-3cd043376a21c461f8605abb2a579f58ff2419e37248c357425a3a143a9d6ecb' removed `A/_darcs/patches/pending' removed `A/_darcs/patches/000110-b044ffccac260b63c9f0f4d92b1c5b85e4221128a9ddf37c12a36415a8d2bdd4' removed `A/_darcs/patches/pending.tentative' removed directory: `A/_darcs/patches' removed `A/_darcs/inventories/000187-198d8c81582fe412f44f446a65a8e40b3b1267107a3e6e72ad2b50a27dbd67e9' removed `A/_darcs/inventories/000369-511de1bfebfc9e3803f8c9d12aef84bf5312f03b013eb16c07709fc8b67ba625' removed directory: `A/_darcs/inventories' removed `A/_darcs/format' removed `A/_darcs/prefs/repos' removed `A/_darcs/prefs/boring' removed `A/_darcs/prefs/author' removed `A/_darcs/prefs/binaries' removed `A/_darcs/prefs/motd' removed `A/_darcs/prefs/defaultrepo' removed directory: `A/_darcs/prefs' removed `A/_darcs/hashed_inventory' removed `A/_darcs/pristine.hashed/000168-cdb7d192d528a5ab1468b5d4339004ddf47442b6bd2d2e2a6f3ba38c724c0883' removed `A/_darcs/pristine.hashed/da39a3ee5e6b4b0d3255bfef95601890afd80709' removed `A/_darcs/pristine.hashed/00-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855' removed `A/_darcs/pristine.hashed/84-555aaf4b6798d05de804c5dd6de6d1707fece5d5d1dcc9dd34c3834e55058b1e' removed directory: `A/_darcs/pristine.hashed' removed directory: `A/_darcs' removed `A/2' removed directory: `A' mich...@isolde:~/junk$ cd B mich...@isolde:~/junk/B$ darcs push darcs failed: Not a repository: /home/michael/junk/A (/home/michael/junk/A/_darcs/inventory: openBinaryFile: does not exist (No such file or directory)) Oops. So much for equal and independent branches! This is what happens when your working set and your repository are one and the same. You create chains of relationships that can *and do* (keep in mind that I have used both Mercurial and Darcs long before I found fossil) lead to lost data and difficult to debug problems. Consider this sequence instead: * I clone a remote repository to A. * Someone else clones my repository A to B. * I make my changes and push them. * The other guy makes his changes and pushes them. * I don't notice this last
Re: [fossil-users] Add files recursively?
Michael Richter wrote: Do you read before you respond? My specific beef was given and it has nothing to do with specifying where I'm pushing to. (Hint: *lost work*.) Huh? You will not lose any work doing what you did: ~/B $ darcs initialize ~/B $ darcs pull ../A ~/B $ touch 3 ~/B $ darcs add 3 ~/B $ darcs record ~/B $ rm -r ~/A ~/B $ darcs push error No work lost. There is nothing in A that B needs. Really. Because, Sparky, when you clone a repo in fossil you have a repository file. That repository file contains the original place you cloned from within it. See my reply to Twylite. Maybe this is how fossil works, but other SCMs have no such thing. Instead, they remember where you pushed or pulled from last time (to save typing). There is no parent unless you go out of your way to make light-weight branches. Btw, apparently Hg doesn't even support light-weight branches. You have to *open* said file to get your working set Maybe in Fossil, but not in the SCMs you are criticizing. Just push or pull from some other place and the SCM will switch to that other location as the default. So when you say fossil commit, fossil knows where to commit because, get this, your working set comes from a repository and has it recorded all automagically-like. Every distributed SCM knows where to commit when I say commit. They all commit to the current branch. That whole separation of concerns thing is what I like about Fossil and what I didn't like about Mercurial or Darcs. I think you don't understand Mercurial or Darcs. With Darcs and Mercurial both I've accidentally turfed repositories that held data as yet un-propagated because I'd forgotten that I'd cloned them to do some work and pushed locally. No. Sorry, but you don't know what you are talking about. Let's see your example again: ~/B $ darcs initialize ~/B $ darcs pull ../A ~/B $ touch 3 ~/B $ darcs add 3 ~/B $ darcs record ~/B $ rm -r ~/A ~/B $ darcs push error After this, B still has everything that it got when it pulled from A. B is a branch. Anyways, I think we'll both agree that Fossil is not for me, so I won't stay here very long. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Hi, Ugh. Your beef is that you have to specify where you are pushing to? That hardly seems like a dependency, or like something that fossil can avoid. How does any SCM, know where I want to push when I just say push? It has to pick some reasonable default such as the place I pushed or pulled from last time. Fossil will have a default too. And if you try to push to a place that doesn't exist I'm sure Fossil will complain. That's hardly a dependency or an inequality between branches. Again, this has absolutely nothing to do with branches. I don't know where you're getting that idea from. Where does Fossil push if I just say fossil push? What if I remove that location? Will Fossil not complain? Or will it somehow know I want to push to some other place? ### Usage: fossil pull ?URL? ?-R|--respository REPOSITORY? Pull changes in a remote repository into the local repository. The repository is identified by the -R or --repository option. If there is no such option then the open repository is used. The URL of the remote server is specified on the command line If no URL is specified then the URL used by the most recent pull, push, or sync command is used. ### Twylite ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Twylite wrote: Again, this has absolutely nothing to do with branches. I don't know where you're getting that idea from. In other SCMs, if I do this: $ cd B $ darcs init $ darcs pull ../A I am creating a new branch B, separate, and independent of A. Ditto for Hg, Git and Bazaar. As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. You made very good points. Let's talk once you understand how fossil actually works...- Altu -Original Message- From: Daniel Carrera dcarr...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Jan 21, 2010 10:11 pm Subject: Re: [fossil-users] Add files recursively? Twylite wrote: Again, this has absolutely nothing to do with branches. I don't know where you're getting that idea from.In other SCMs, if I do this:$ cd B$ darcs init$ darcs pull ../AI am creating a new branch B, separate, and independent of A. Ditto for Hg, Git and Bazaar. As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist.Daniel.___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Hi, this may be worth a look https://www.drproject.org/ DrProject is a web-based project management portal that integrates revision control, issue tracking, mailing lists, a wiki, and other tools that software development teams need to succeed. DrProject was designed to be simple enough for undergraduate students to master in less than an hour, and is now being used by universities, open source projects, and commercial teams in several companies. On Thursday, January 21, 2010, altufa...@mail.com wrote: As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. You made very good points. Let's talk once you understand how fossil actually works...- Altu -Original Message- From: Daniel Carrera dcarr...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Jan 21, 2010 10:11 pm Subject: Re: [fossil-users] Add files recursively? Twylite wrote: Again, this has absolutely nothing to do with branches. I don't know where you're getting that idea from. In other SCMs, if I do this: $ cd B $ darcs init $ darcs pull ../A I am creating a new branch B, separate, and independent of A. Ditto for Hg, Git and Bazaar. As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Thanks. That really does sound promising. Daniel. Stephen De Gabrielle wrote: Hi, this may be worth a look https://www.drproject.org/ DrProject is a web-based project management portal that integrates revision control, issue tracking, mailing lists, a wiki, and other tools that software development teams need to succeed. DrProject was designed to be simple enough for undergraduate students to master in less than an hour, and is now being used by universities, open source projects, and commercial teams in several companies. On Thursday, January 21, 2010, altufa...@mail.com wrote: As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. You made very good points. Let's talk once you understand how fossil actually works...- Altu -Original Message- From: Daniel Carrera dcarr...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Jan 21, 2010 10:11 pm Subject: Re: [fossil-users] Add files recursively? Twylite wrote: Again, this has absolutely nothing to do with branches. I don't know where you're getting that idea from. In other SCMs, if I do this: $ cd B $ darcs init $ darcs pull ../A I am creating a new branch B, separate, and independent of A. Ditto for Hg, Git and Bazaar. As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
it also seems to have a successor - thought I don't know how well 'baked' it is. http://basieproject.org/ PS I don't use either of these - I use Fossil :) On Thu, Jan 21, 2010 at 7:40 PM, Daniel Carrera dcarr...@gmail.com wrote: Thanks. That really does sound promising. Daniel. Stephen De Gabrielle wrote: Hi, this may be worth a look https://www.drproject.org/ DrProject is a web-based project management portal that integrates revision control, issue tracking, mailing lists, a wiki, and other tools that software development teams need to succeed. DrProject was designed to be simple enough for undergraduate students to master in less than an hour, and is now being used by universities, open source projects, and commercial teams in several companies. On Thursday, January 21, 2010, altufa...@mail.com wrote: As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. You made very good points. Let's talk once you understand how fossil actually works...- Altu -Original Message- From: Daniel Carrera dcarr...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Jan 21, 2010 10:11 pm Subject: Re: [fossil-users] Add files recursively? Twylite wrote: Again, this has absolutely nothing to do with branches. I don't know where you're getting that idea from. In other SCMs, if I do this: $ cd B $ darcs init $ darcs pull ../A I am creating a new branch B, separate, and independent of A. Ditto for Hg, Git and Bazaar. As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
On Jan 21, 2010, at 6:38 PM, Stephen De Gabrielle wrote: it also seems to have a successor - thought I don't know how well 'baked' it is. http://basieproject.org/ Both projects seem to be a big website that is installed. Purely client/server. No support for disconnected operation. Do I have that right, or did I miss something? D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Thanks again. Also worth a look. One thing I don't like about Basie and Dr Project is that they rely on subversion, but the might still be the best choice for what I need. Another option I'm considering is to use Launchpad. Launchpad seems to have most of the features I want, I wouldn't have to administer it, and it actually relies on a good DVCS. Daniel. Stephen De Gabrielle wrote: it also seems to have a successor - thought I don't know how well 'baked' it is. http://basieproject.org/ PS I don't use either of these - I use Fossil :) On Thu, Jan 21, 2010 at 7:40 PM, Daniel Carrera dcarr...@gmail.com mailto:dcarr...@gmail.com wrote: Thanks. That really does sound promising. Daniel. Stephen De Gabrielle wrote: Hi, this may be worth a look https://www.drproject.org/ DrProject is a web-based project management portal that integrates revision control, issue tracking, mailing lists, a wiki, and other tools that software development teams need to succeed. DrProject was designed to be simple enough for undergraduate students to master in less than an hour, and is now being used by universities, open source projects, and commercial teams in several companies. On Thursday, January 21, 2010, altufa...@mail.com mailto:altufa...@mail.com wrote: As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. You made very good points. Let's talk once you understand how fossil actually works...- Altu -Original Message- From: Daniel Carrera dcarr...@gmail.com mailto:dcarr...@gmail.com To: fossil-users@lists.fossil-scm.org mailto:fossil-users@lists.fossil-scm.org Sent: Thu, Jan 21, 2010 10:11 pm Subject: Re: [fossil-users] Add files recursively? Twylite wrote: Again, this has absolutely nothing to do with branches. I don't know where you're getting that idea from. In other SCMs, if I do this: $ cd B $ darcs init $ darcs pull ../A I am creating a new branch B, separate, and independent of A. Ditto for Hg, Git and Bazaar. As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org mailto:fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org mailto:fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- -- Stephen De Gabrielle stephen.degabrie...@acm.org mailto:stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
D. Richard Hipp wrote: Both projects seem to be a big website that is installed. Purely client/server. No support for disconnected operation. Do I have that right, or did I miss something? They are both based on subversion, so my guess would be yes. So it's definitely not something I'd use for my own work, but it might still be the right solution for the users I have in mind. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
On Jan 20, 2010, at 4:58 PM, Daniel Carrera wrote: D. Richard Hipp wrote: fossil add directory-name That recursively adds all files contained within the directory. Thanks. Now fossil polluted my root directory with several files (__FOSSIL__, manifest, manifest.uuid). Is that normal? is there anything I can do about that? Other SCMs are nice enough to put everything in one directory so they don't pollute my root directory too much (e.g. _darcs/ contains all the files darcs needs). __FOSSIL__ is required, though you can rename it to .fos if you don't want to look at it. This is the equivalent to _darcs/ or CVS/ or whatever. But it is a single file (an SQLite database) rather than a directory. manifest and manifest.uuid are convenience information files. They are not used by Fossil. Fossil provides them to you for your information. You can delete them if you want. I think they will come back, though, the next time you check-in our check-out. There have been a number of requests to add an option to omit those files. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
D. Richard Hipp wrote: __FOSSIL__ is required, though you can rename it to .fos if you don't want to look at it. This is the equivalent to _darcs/ or CVS/ or whatever. But it is a single file (an SQLite database) rather than a directory. manifest and manifest.uuid are convenience information files. They are not used by Fossil. Fossil provides them to you for your information. You can delete them if you want. I think they will come back, though, the next time you check-in our check-out. There have been a number of requests to add an option to omit those files. Are you open to the idea of having a _fossil or .fossil directory where these files go? Seems better than deleting maniest* every time I sync. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
FWIW, I create a check-out directory for each project, then create a symlink in the check-out directory to the project's working dir(s). That keeps _FOSSIL_ and the manifest files out of my working dir, and gives me a place to create scm-specific scripts, notes, and a file detailing the changes (changes.txt) for when it's time to commit. From the checkout, it's easy to fossil add working/somefile This works in Windows, too, using junctions instead of symlinks. -Clark - Original Message From: Daniel Carrera dcarr...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Wed, January 20, 2010 2:37:09 PM Subject: Re: [fossil-users] Add files recursively? D. Richard Hipp wrote: __FOSSIL__ is required, though you can rename it to .fos if you don't want to look at it. This is the equivalent to _darcs/ or CVS/ or whatever. But it is a single file (an SQLite database) rather than a directory. manifest and manifest.uuid are convenience information files. They are not used by Fossil. Fossil provides them to you for your information. You can delete them if you want. I think they will come back, though, the next time you check-in our check-out. There have been a number of requests to add an option to omit those files. Are you open to the idea of having a _fossil or .fossil directory where these files go? Seems better than deleting maniest* every time I sync. Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Add files recursively?
Paul Serice wrote: __FOSSIL__ is required, though you can rename it to .fos if you don't want to look at it. This is dangerous because the following commands do very bad things: fossil extras --dotfiles fossil clean -f --dotfiles Then it is a mis-feature (or bug) that you can turn __FOSSIL__ into .fos (or that there are --dotfiles options). I don't understand why Fossil has to put four files in my root directory (myproj.fossil, __FOSSIL__, manifest, manifest.uuid). Why can't it have a single directory like _fossil/ just like every other decent SCM today? That directory should include the two database files (so I don't have to wonder why you need *TWO* database files -- I thought you were supposed to have only one) and it should include the manifest files (so that Michael can use them in his project bills without Daniel getting annoyed that they keep polluting his root directory). Daniel. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users