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, then
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
[fossil-users] Noob windows build problems
Hello,
I have fossil source code: fossil-src-20091220213451
I have setup Ming and MSYS (http://www.mingw.org/wiki/msys). Attempting to
compile gives me an error caused by a missing zlib.h. I am guessing this
means I need to include source code for zlib. Can someone point me in the
right direction to get fossil compiled from scratch? Here is the full
output:
$ make -f Makefile.w32
gcc -g -O2 -o translate ./src/translate.c
./translate ./src/add.c add_.c
./translate ./src/allrepo.c allrepo_.c
./translate ./src/bag.c bag_.c
./translate ./src/blob.c blob_.c
./translate ./src/branch.c branch_.c
./translate ./src/browse.c browse_.c
./translate ./src/captcha.c captcha_.c
./translate ./src/cgi.c cgi_.c
./translate ./src/checkin.c checkin_.c
./translate ./src/checkout.c checkout_.c
./translate ./src/clearsign.c clearsign_.c
./translate ./src/clone.c clone_.c
./translate ./src/comformat.c comformat_.c
./translate ./src/configure.c configure_.c
./translate ./src/construct.c construct_.c
./translate ./src/content.c content_.c
./translate ./src/db.c db_.c
./translate ./src/delta.c delta_.c
./translate ./src/deltacmd.c deltacmd_.c
./translate ./src/descendants.c descendants_.c
./translate ./src/diff.c diff_.c
./translate ./src/diffcmd.c diffcmd_.c
./translate ./src/doc.c doc_.c
./translate ./src/encode.c encode_.c
./translate ./src/file.c file_.c
./translate ./src/finfo.c finfo_.c
./translate ./src/http.c http_.c
./translate ./src/http_socket.c http_socket_.c
./translate ./src/http_transport.c http_transport_.c
./translate ./src/info.c info_.c
./translate ./src/login.c login_.c
./translate ./src/main.c main_.c
./translate ./src/manifest.c manifest_.c
./translate ./src/md5.c md5_.c
./translate ./src/merge.c merge_.c
./translate ./src/merge3.c merge3_.c
./translate ./src/name.c name_.c
./translate ./src/pivot.c pivot_.c
./translate ./src/pqueue.c pqueue_.c
./translate ./src/printf.c printf_.c
./translate ./src/rebuild.c rebuild_.c
./translate ./src/report.c report_.c
./translate ./src/rss.c rss_.c
./translate ./src/rstats.c rstats_.c
./translate ./src/schema.c schema_.c
./translate ./src/search.c search_.c
./translate ./src/setup.c setup_.c
./translate ./src/sha1.c sha1_.c
./translate ./src/shun.c shun_.c
./translate ./src/skins.c skins_.c
./translate ./src/stat.c stat_.c
./translate ./src/style.c style_.c
./translate ./src/sync.c sync_.c
./translate ./src/tag.c tag_.c
./translate ./src/th_main.c th_main_.c
./translate ./src/timeline.c timeline_.c
./translate ./src/tkt.c tkt_.c
./translate ./src/tktsetup.c tktsetup_.c
./translate ./src/undo.c undo_.c
./translate ./src/update.c update_.c
./translate ./src/url.c url_.c
./translate ./src/user.c user_.c
./translate ./src/verify.c verify_.c
./translate ./src/vfile.c vfile_.c
./translate ./src/wiki.c wiki_.c
./translate ./src/wikiformat.c wikiformat_.c
./translate ./src/winhttp.c winhttp_.c
./translate ./src/xfer.c xfer_.c
./translate ./src/zip.c zip_.c
gcc -g -O2 -o mkindex ./src/mkindex.c
./mkindex add_.c allrepo_.c bag_.c blob_.c branch_.c browse_.c captcha_.c
cgi_.c
checkin_.c checkout_.c clearsign_.c clone_.c comformat_.c configure_.c
construc
t_.c content_.c db_.c delta_.c deltacmd_.c descendants_.c diff_.c diffcmd_.c
doc
_.c encode_.c file_.c finfo_.c http_.c http_socket_.c http_transport_.c
info_.c
login_.c main_.c manifest_.c md5_.c merge_.c merge3_.c name_.c pivot_.c
pqueue_.
c printf_.c rebuild_.c report_.c rss_.c rstats_.c schema_.c search_.c
setup_.c s
ha1_.c shun_.c skins_.c stat_.c style_.c sync_.c tag_.c th_main_.c
timeline_.c t
kt_.c tktsetup_.c undo_.c update_.c url_.c user_.c verify_.c vfile_.c
wiki_.c wi
kiformat_.c winhttp_.c xfer_.c zip_.c page_index.h
gcc -g -O2 -o makeheaders ./src/makeheaders.c
awk '{ printf #define MANIFEST_UUID \%s\\n, $1}' ./src/../manifest.uuid
VE
RSION.h
awk '{ printf #define MANIFEST_VERSION \[%.10s]\\n, $1}'
./src/../manifest.
uuid VERSION.h
awk '$1==D{printf #define MANIFEST_DATE \%s %s\\n,
substr($2,1,10),substr(
$2,12)}' ./src/../manifest VERSION.h
./makeheaders add_.c:add.h allrepo_.c:allrepo.h bag_.c:bag.h blob_.c:blob.h
bra
nch_.c:branch.h browse_.c:browse.h captcha_.c:captcha.h cgi_.c:cgi.h
checkin_.c:
checkin.h checkout_.c:checkout.h clearsign_.c:clearsign.h clone_.c:clone.h
comfo
rmat_.c:comformat.h configure_.c:configure.h construct_.c:construct.h
content_.c
:content.h db_.c:db.h delta_.c:delta.h deltacmd_.c:deltacmd.h
descendants_.c:des
cendants.h diff_.c:diff.h diffcmd_.c:diffcmd.h doc_.c:doc.h
encode_.c:encode.h f
ile_.c:file.h finfo_.c:finfo.h http_.c:http.h http_socket_.c:http_socket.h
http_
transport_.c:http_transport.h info_.c:info.h login_.c:login.h main_.c:main.h
man
ifest_.c:manifest.h md5_.c:md5.h merge_.c:merge.h merge3_.c:merge3.h
name_.c:nam
e.h pivot_.c:pivot.h pqueue_.c:pqueue.h printf_.c:printf.h
rebuild_.c:rebuild.h
report_.c:report.h rss_.c:rss.h rstats_.c:rstats.h schema_.c:schema.h
search_.c:
search.h setup_.c:setup.h sha1_.c:sha1.h shun_.c:shun.h skins_.c:skins.h
stat_.c
:stat.h
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] Noob windows build problems
You need to have zlib built and the library in your library path. Google
for zlib and download it, compile it and place it in your lib directory for
MinGW/MSYS.
2010/1/21 Simon Horton sij.hor...@gmail.com
Hello,
I have fossil source code: fossil-src-20091220213451
I have setup Ming and MSYS (http://www.mingw.org/wiki/msys). Attempting to
compile gives me an error caused by a missing zlib.h. I am guessing this
means I need to include source code for zlib. Can someone point me in the
right direction to get fossil compiled from scratch? Here is the full
output:
$ make -f Makefile.w32
gcc -g -O2 -o translate ./src/translate.c
./translate ./src/add.c add_.c
./translate ./src/allrepo.c allrepo_.c
./translate ./src/bag.c bag_.c
./translate ./src/blob.c blob_.c
./translate ./src/branch.c branch_.c
./translate ./src/browse.c browse_.c
./translate ./src/captcha.c captcha_.c
./translate ./src/cgi.c cgi_.c
./translate ./src/checkin.c checkin_.c
./translate ./src/checkout.c checkout_.c
./translate ./src/clearsign.c clearsign_.c
./translate ./src/clone.c clone_.c
./translate ./src/comformat.c comformat_.c
./translate ./src/configure.c configure_.c
./translate ./src/construct.c construct_.c
./translate ./src/content.c content_.c
./translate ./src/db.c db_.c
./translate ./src/delta.c delta_.c
./translate ./src/deltacmd.c deltacmd_.c
./translate ./src/descendants.c descendants_.c
./translate ./src/diff.c diff_.c
./translate ./src/diffcmd.c diffcmd_.c
./translate ./src/doc.c doc_.c
./translate ./src/encode.c encode_.c
./translate ./src/file.c file_.c
./translate ./src/finfo.c finfo_.c
./translate ./src/http.c http_.c
./translate ./src/http_socket.c http_socket_.c
./translate ./src/http_transport.c http_transport_.c
./translate ./src/info.c info_.c
./translate ./src/login.c login_.c
./translate ./src/main.c main_.c
./translate ./src/manifest.c manifest_.c
./translate ./src/md5.c md5_.c
./translate ./src/merge.c merge_.c
./translate ./src/merge3.c merge3_.c
./translate ./src/name.c name_.c
./translate ./src/pivot.c pivot_.c
./translate ./src/pqueue.c pqueue_.c
./translate ./src/printf.c printf_.c
./translate ./src/rebuild.c rebuild_.c
./translate ./src/report.c report_.c
./translate ./src/rss.c rss_.c
./translate ./src/rstats.c rstats_.c
./translate ./src/schema.c schema_.c
./translate ./src/search.c search_.c
./translate ./src/setup.c setup_.c
./translate ./src/sha1.c sha1_.c
./translate ./src/shun.c shun_.c
./translate ./src/skins.c skins_.c
./translate ./src/stat.c stat_.c
./translate ./src/style.c style_.c
./translate ./src/sync.c sync_.c
./translate ./src/tag.c tag_.c
./translate ./src/th_main.c th_main_.c
./translate ./src/timeline.c timeline_.c
./translate ./src/tkt.c tkt_.c
./translate ./src/tktsetup.c tktsetup_.c
./translate ./src/undo.c undo_.c
./translate ./src/update.c update_.c
./translate ./src/url.c url_.c
./translate ./src/user.c user_.c
./translate ./src/verify.c verify_.c
./translate ./src/vfile.c vfile_.c
./translate ./src/wiki.c wiki_.c
./translate ./src/wikiformat.c wikiformat_.c
./translate ./src/winhttp.c winhttp_.c
./translate ./src/xfer.c xfer_.c
./translate ./src/zip.c zip_.c
gcc -g -O2 -o mkindex ./src/mkindex.c
./mkindex add_.c allrepo_.c bag_.c blob_.c branch_.c browse_.c captcha_.c
cgi_.c
checkin_.c checkout_.c clearsign_.c clone_.c comformat_.c configure_.c
construc
t_.c content_.c db_.c delta_.c deltacmd_.c descendants_.c diff_.c
diffcmd_.c doc
_.c encode_.c file_.c finfo_.c http_.c http_socket_.c http_transport_.c
info_.c
login_.c main_.c manifest_.c md5_.c merge_.c merge3_.c name_.c pivot_.c
pqueue_.
c printf_.c rebuild_.c report_.c rss_.c rstats_.c schema_.c search_.c
setup_.c s
ha1_.c shun_.c skins_.c stat_.c style_.c sync_.c tag_.c th_main_.c
timeline_.c t
kt_.c tktsetup_.c undo_.c update_.c url_.c user_.c verify_.c vfile_.c
wiki_.c wi
kiformat_.c winhttp_.c xfer_.c zip_.c page_index.h
gcc -g -O2 -o makeheaders ./src/makeheaders.c
awk '{ printf #define MANIFEST_UUID \%s\\n, $1}'
./src/../manifest.uuid VE
RSION.h
awk '{ printf #define MANIFEST_VERSION \[%.10s]\\n, $1}'
./src/../manifest.
uuid VERSION.h
awk '$1==D{printf #define MANIFEST_DATE \%s %s\\n,
substr($2,1,10),substr(
$2,12)}' ./src/../manifest VERSION.h
./makeheaders add_.c:add.h allrepo_.c:allrepo.h bag_.c:bag.h
blob_.c:blob.h bra
nch_.c:branch.h browse_.c:browse.h captcha_.c:captcha.h cgi_.c:cgi.h
checkin_.c:
checkin.h checkout_.c:checkout.h clearsign_.c:clearsign.h clone_.c:clone.h
comfo
rmat_.c:comformat.h configure_.c:configure.h construct_.c:construct.h
content_.c
:content.h db_.c:db.h delta_.c:delta.h deltacmd_.c:deltacmd.h
descendants_.c:des
cendants.h diff_.c:diff.h diffcmd_.c:diffcmd.h doc_.c:doc.h
encode_.c:encode.h f
ile_.c:file.h finfo_.c:finfo.h http_.c:http.h http_socket_.c:http_socket.h
http_
transport_.c:http_transport.h info_.c:info.h login_.c:login.h
main_.c:main.h man
[fossil-users] Publicize FOSSIL
Would any of you consider appearing on the podcast FLOSS Weekly (http://twit.tv/floss) to talk about FOSSIL ? This would be an excellent chance to get the word out about how good and useful a tool this is. They have a wide audience and it would spark a lot of interest in the project. Also as part of the interview they always ask what sort of help the project can use. You can check on the website to listen to shows and also see the projects he, Leo Laporte and Jono Bacon (from Ubuntu) have covered. The host (Randal Schwartz) stated, projects that contact him with potential interviewees would get bumped up in the schedule. The spokesman should contact him at mer...@stonehenge.com. I'm just writing as a happy user that would like to get this wonderful tool some more publicity. --jim schimpf ___ 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, 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] Publicize FOSSIL
On Jan 21, 2010, at 8:59 AM, verizon wrote: Would any of you consider appearing on the podcast FLOSS Weekly (http://twit.tv/floss ) to talk about FOSSIL ? This would be an excellent chance to get the word out about how good and useful a tool this is. They have a wide audience and it would spark a lot of interest in the project. Also as part of the interview they always ask what sort of help the project can use. You can check on the website to listen to shows and also see the projects he, Leo Laporte and Jono Bacon (from Ubuntu) have covered. The host (Randal Schwartz) stated, projects that contact him with potential interviewees would get bumped up in the schedule. The spokesman should contact him at mer...@stonehenge.com. I'm just writing as a happy user that would like to get this wonderful tool some more publicity. Randal has interviewed me before (though about SQLite, not Fossil). http://twit.tv/floss26 But if he and others think it is worthwhile, I'll be happy to do another interview... 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?
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] Publicize FOSSIL
On Thu, Jan 21, 2010 at 09:07:35AM -0500, D. Richard Hipp wrote: On Jan 21, 2010, at 8:59 AM, verizon wrote: Would any of you consider appearing on the podcast FLOSS Weekly (http://twit.tv/floss ) to talk about FOSSIL ? This would be an excellent chance to get the word out about how good and useful a tool this is. They have a wide audience and it would spark a lot of interest in the project. Also as part of the interview they always ask what sort of help the project can use. You can check on the website to listen to shows and also see the projects he, Leo Laporte and Jono Bacon (from Ubuntu) have covered. The host (Randal Schwartz) stated, projects that contact him with potential interviewees would get bumped up in the schedule. The spokesman should contact him at mer...@stonehenge.com. I'm just writing as a happy user that would like to get this wonderful tool some more publicity. Randal has interviewed me before (though about SQLite, not Fossil). http://twit.tv/floss26 But if he and others think it is worthwhile, I'll be happy to do another interview... D. Richard Hipp d...@hwaci.com ___ I think that it would be useful to provide more people the opportunity to learn about fossil. ~Michael -- Michael McDaniel Portland, Oregon, USA http://trip.autosys.us http://putitgetit.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?
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] Publicize FOSSIL
Yes, please. I have been meaning to suggest the same. Your SQLite interview there was interesting, and informative, even for someone like me, who follows SQLite's progress through the mailing list. I think it would be great to have you talk about Fossil there, and to also talk about how SQLite has advanced since the previous interview. -Clark - Original Message From: D. Richard Hipp d...@hwaci.com To: fossil-users@lists.fossil-scm.org Sent: Thu, January 21, 2010 6:07:35 AM Subject: Re: [fossil-users] Publicize FOSSIL On Jan 21, 2010, at 8:59 AM, verizon wrote: Would any of you consider appearing on the podcast FLOSS Weekly (http://twit.tv/floss ) to talk about FOSSIL ? This would be an excellent chance to get the word out about how good and useful a tool this is. They have a wide audience and it would spark a lot of interest in the project. Also as part of the interview they always ask what sort of help the project can use. You can check on the website to listen to shows and also see the projects he, Leo Laporte and Jono Bacon (from Ubuntu) have covered. The host (Randal Schwartz) stated, projects that contact him with potential interviewees would get bumped up in the schedule. The spokesman should contact him at mer...@stonehenge.com. I'm just writing as a happy user that would like to get this wonderful tool some more publicity. Randal has interviewed me before (though about SQLite, not Fossil). http://twit.tv/floss26 But if he and others think it is worthwhile, I'll be happy to do another interview... 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 ___ 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] cloning http://www.fossil-scm.org/ fails
On Jan 21, 2010, at 7:35 PM, Kyle McKay wrote: I just recently tried to clone http://www.fossil-scm.org/, but it fails: fossil clone http://www.fossil-scm.org/ fossil.fossil Bytes Cards Artifacts Deltas Send: 49 1 0 0 Received: 20 1 0 0 Send: 619 24 0 0 1Server Error: login failed fossil: server says: login failed Is that expected? Do I need to get a login in order to be able to clone? All 3 of the URLs listed on: http://www.fossil-scm.org/fossil/doc/tip/www/selfhost.wiki fail with the same error on a clone attempt. I made some changes to the way the sync server works - it is much stricter about logins now. If the userid/password is wrong, it aborts straightaway, whereas before it would continue running, but with the privileges of user nobody. This is OK with the corresponding version of the client, since the latest client code doesn't even attempt to login if no login credentials are provided. However, the old client tries to login even if not credentials are given. So this doesn't work well with the new server. Oops. I'll work on a fix. Please try again in a few hours 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] cloning http://www.fossil-scm.org/ fails
On Jan 21, 2010, at 7:57 PM, D. Richard Hipp wrote: On Jan 21, 2010, at 7:35 PM, Kyle McKay wrote: All 3 of the URLs listed on: http://www.fossil-scm.org/fossil/doc/tip/www/selfhost.wiki fail with the same error on a clone attempt. I'll work on a fix. Please try again in a few hours Better: Just download the latest precompiled binary or tarball from http://www.fossil-scm.org/download.html and use that instead of the version you are currently using. With the new client, you don't need to include the password in the URL of a sync. Instead of: fossil sync http://userid:passw...@example.com/ You just include the userid, like this: fossil sync http://use...@example.com/ And it prompts you for the password. So people looking over your shoulder can't see your password. And if you enter the wrong password, it tells you and asks again. Or if your password changes and you do just: fossil sync It will prompt you to enter a new password (which it of course remembers for the next sync...) So, I didn't break stuff arbitrarily. I really am trying to make things better. Thanks for your patience. 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
