Discussion:
Add files recursively?
(too old to reply)
Daniel Carrera
2010-01-20 21:16:40 UTC
Permalink
Hello,

How do you add files recursively? I want to add an entire directory tree
to a fossil database. It's too many files to add them all one by one.

Daniel.
D. Richard Hipp
2010-01-20 21:34:54 UTC
Permalink
Post by Daniel Carrera
Hello,
How do you add files recursively? I want to add an entire directory tree
to a fossil database. It's too many files to add them all one by one.
fossil add directory-name

That recursively adds all files contained within the directory.

D. Richard Hipp
***@hwaci.com
Daniel Carrera
2010-01-20 21:58:12 UTC
Permalink
Post by D. Richard Hipp
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).

Daniel.
D. Richard Hipp
2010-01-20 22:23:56 UTC
Permalink
Post by Daniel Carrera
Post by D. Richard Hipp
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.
Post by Daniel Carrera
Daniel.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
D. Richard Hipp
***@hwaci.com
Daniel Carrera
2010-01-20 22:37:09 UTC
Permalink
Post by D. Richard Hipp
__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.
D. Richard Hipp
2010-01-20 22:39:43 UTC
Permalink
Post by Daniel Carrera
Post by D. Richard Hipp
__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.
I'll add a setting to suppress the manifest files.
Post by Daniel Carrera
Daniel.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
D. Richard Hipp
***@hwaci.com
Michael
2010-01-20 22:45:42 UTC
Permalink
Post by D. Richard Hipp
Post by Daniel Carrera
Post by D. Richard Hipp
__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.
I'll add a setting to suppress the manifest files.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Presumably (please) as an exception to current default of having
the manifest files ?

I use them during my project builds for creating version macros
used in my software.

~Michael
Post by D. Richard Hipp
Post by Daniel Carrera
Daniel.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
D. Richard Hipp
Clark Christensen
2010-01-20 23:01:08 UTC
Permalink
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.
Paul Serice
2010-01-21 00:25:19 UTC
Permalink
Post by D. Richard Hipp
__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

Thank You,
Paul Serice
Daniel Carrera
2010-01-21 07:19:52 UTC
Permalink
Post by Paul Serice
Post by D. Richard Hipp
__FOSSIL__ is required, though you can rename it to ".fos" if you
don't want to look at it.
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.
Ramon Ribó
2010-01-21 08:49:43 UTC
Permalink
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
Post by Daniel Carrera
Post by D. Richard Hipp
__FOSSIL__ is required, though you can rename it to ".fos" if you
don't want to look at it.
    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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Daniel Carrera
2010-01-21 08:57:32 UTC
Permalink
Post by Ramon Ribó
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.
Ramon Ribó
2010-01-21 09:16:45 UTC
Permalink
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
Post by Daniel Carrera
Post by Ramon Ribó
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Daniel Carrera
2010-01-21 09:46:23 UTC
Permalink
Post by Ramon Ribó
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.
Post by Ramon Ribó
- 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.
Post by Ramon Ribó
- 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".
Post by Ramon Ribó
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.
Michael Richter
2010-01-21 10:17:42 UTC
Permalink
Post by Daniel Carrera
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.

2) But the truth is that there *are* other files. You can move them to
Post by Daniel Carrera
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.

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).

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? B is expecting A as an uplink which is now gone because the
distinction between the working set and the repository is fuzzy. 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.

Fossil keeps the concept of the repository and the working set distinct.
When I clone a remote repository, I make a local copy of the repository. I
still don't have a working set. I then open that repository for feature A
and get my working set. The working set is physically and logically
entirely distinct from the repository (and IMO a smart user will keep them
widely separated). It is a snapshot of the repo, in effect. While I'm
working on A, I get my request to work on B. I make another snapshot of the
same repository and now I have one repository and two working sets (instead
of the hg/darcs odd blend of two repositories and two working sets kind of
smushed together). When I'm finished with A, I commit and push and can wipe
out the working set without worrying about what other working sets rely upon
it because none do. When I finish with B, I commit (resolving any clashes
in the interim) but I don't have to reseat the upstream (or some of the more
arcane things other DSCMs have to do).

In the end, when I'm working with more than one snapshot of the repo at a
time, I've got FEWER entities to worry about. Instead of having Nx2 things
(one repository and one working set for each of N snapshots) I have N+1
things (one repository and N snapshots). I also have the advantage of the
repository being in a bulletproof database wrapper, and a single file for
ease of backup, transportation, copying, etc.
Post by Daniel Carrera
Post by Ramon Ribó
- 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".
Notice the other disclaimer: work in progress. Richard is constantly
working on improving and upgrading fossil as users spot needs and flaws. If
you're scared of change, perhaps another SCM is for you. One that hasn't
had any development (or even maintenance) done for a few years, say.
Post by Daniel Carrera
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.
Post by Daniel Carrera
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.
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
interested I'll give you links to them. Perhaps one of them will suit you
better.

I do know that as a former user of both hg and darcs I find fossil a much
better solution for a wide variety of reasons, but YMMV and all that jazz.
Daniel Carrera
2010-01-21 10:43:28 UTC
Permalink
Post by Daniel Carrera
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.
Post by Daniel Carrera
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.
Post by Daniel Carrera
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.
Post by Daniel Carrera
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.
Post by Daniel Carrera
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".
Post by Daniel Carrera
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.
Post by Daniel Carrera
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.
Post by Daniel Carrera
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.
Post by Daniel Carrera
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 interested I'll give you links to them.
Perhaps one of them will suit you better.
I hate centralized SCMs. I currently like Darcs, Mercurial and Bazaar. I
was looking at fossil because I thought it might solve a problem for me,
but I don't think that it will.

Daniel.
a***@mail.com
2010-01-21 12:00:47 UTC
Permalink
Wait... read this:



C:\>md repo
C:\>cd repo
C:\repo>fossil new actual.fossil
blah...
C:\repo>cd ..
C:\>md waA
C:\>cd waA
C:\waA>fossil open ..\repo\actual.fossil
C:\waA>cd ..
C:\>md waB
C:\>cd waB
C:\waB>fossil open ..\repo\actual.fossil
C:\waB>cd ..
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 <***@gmail.com>
To: fossil-***@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 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 interested I'll give you links to them. > Perhaps one of them will suit you better.I hate centralized SCMs. I currently like Darcs, Mercurial and Bazaar. I was looking at fossil because I thought it might solve a problem for me, but I don't think that it will.Daniel._______________________________________________fossil-users mailing listfossil-***@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Ron Aaron
2010-01-21 10:34:24 UTC
Permalink
Post by Daniel Carrera
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.
...
Post by Daniel Carrera
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
Daniel Carrera
2010-01-21 10:55:56 UTC
Permalink
Post by Ron Aaron
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.
Post by Ron Aaron
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.
Post by Ron Aaron
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.
Post by Ron Aaron
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.
Twylite
2010-01-21 12:10:00 UTC
Permalink
Hi,
Post by Daniel Carrera
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.
Then use Visual SourceSafe, or Subversion. They are simple to
understand: a network filesystem with an added dimension for time
(revisions).

With any DVCS users must understand the distinction between a repository
and a working set, and they must understand branching and merging.
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" "?!?").

These are not simple concepts. In development companies it can take new
recruits (graduates, possibly with experience) weeks to get comfortable
with a VCS, and indications are that DVCS takes longer.

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. 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.
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).
Post by Daniel Carrera
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.
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).
Post by Daniel Carrera
Post by Michael Richter
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.
When you clone REMOTE to A, a note is made in A that you cloned from
REMOTE. So when you are working in A and you push or pull or sync it
knows that the endpoint of that operation is REMOTE.

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.

Then you delete A. And you go into B and make some changes, and commit,
and push. And it says "Can't. A is missing". And you have to
explicitly tell it that you want to sync with REMOTE instead of A.

That sequence applies to Fossil, Git, Hg, Bazaar, and DVCS in general.

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.

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.
Post by Daniel Carrera
Post by Michael Richter
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. Then they muck with
hardlinks and copy-on-write to try and conserve disk space and improve
performance. (You don't want to use these on a FAT32 filesystem)

Regards,
Twylite
Daniel Carrera
2010-01-21 12:29:32 UTC
Permalink
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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".
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
Post by Daniel Carrera
Post by Michael Richter
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 doesn't force you
to put all the changes in your working directory. There's an important
distinction there. I can sync my repository with you, but not apply your
changes to my working tree. Or I can apply some of your changes but not
others.
Post by Twylite
Then they muck with
hardlinks and copy-on-write to try and conserve disk space and improve
performance. (You don't want to use these on a FAT32 filesystem)
Some muck with hard links, others don't. AFAIK it is Hg that uses hard
links.

Daniel.
Michael Richter
2010-01-21 13:23:49 UTC
Permalink
Post by Daniel Carrera
Post by Twylite
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.

***@isolde:~/junk$ mkdir A B Remote
***@isolde:~/junk$ cd Remote
***@isolde:~/junk/Remote$ darcs initialize
***@isolde:~/junk/Remote$ touch 1
***@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'
***@isolde:~/junk/Remote$ cd ../A
***@isolde:~/junk/A$ darcs initialize ; darcs pull ../Remote
Thu Jan 21 21:01:48 CST 2010 ***@gmail.com
* file 1 in Remote
Shall I pull this patch? (1/1) [ynWsfvplxdaqjk], or ? for help: a
Finished pulling and applying.
***@isolde:~/junk/A$ touch 2
***@isolde:~/junk/A$ darcs add 2
***@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'
***@isolde:~/junk/A$ cd ../B
***@isolde:~/junk/B$ darcs initialize
***@isolde:~/junk/B$ darcs pull ../A
Thu Jan 21 21:01:48 CST 2010 ***@gmail.com
* file 1 in Remote
Shall I pull this patch? (1/2) [ynWsfvplxdaqjk], or ? for help: a
Finished pulling and applying.
***@isolde:~/junk/B$ touch 3
***@isolde:~/junk/B$ darcs add 3
***@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:

***@isolde:~/junk/B$ cd ..
***@isolde:~/junk$ rm -fR A
removed `A/1'
removed `A/_darcs/tentative_pristine'
removed
`A/_darcs/patches/0000000115-3cd043376a21c461f8605abb2a579f58ff2419e37248c357425a3a143a9d6ecb'
removed `A/_darcs/patches/pending'
removed
`A/_darcs/patches/0000000110-b044ffccac260b63c9f0f4d92b1c5b85e4221128a9ddf37c12a36415a8d2bdd4'
removed `A/_darcs/patches/pending.tentative'
removed directory: `A/_darcs/patches'
removed
`A/_darcs/inventories/0000000187-198d8c81582fe412f44f446a65a8e40b3b1267107a3e6e72ad2b50a27dbd67e9'
removed
`A/_darcs/inventories/0000000369-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/0000000168-cdb7d192d528a5ab1468b5d4339004ddf47442b6bd2d2e2a6f3ba38c724c0883'
removed `A/_darcs/pristine.hashed/da39a3ee5e6b4b0d3255bfef95601890afd80709'
removed
`A/_darcs/pristine.hashed/0000000000-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
removed
`A/_darcs/pristine.hashed/0000000084-555aaf4b6798d05de804c5dd6de6d1707fece5d5d1dcc9dd34c3834e55058b1e'
removed directory: `A/_darcs/pristine.hashed'
removed directory: `A/_darcs'
removed `A/2'
removed directory: `A'
***@isolde:~/junk$ cd B
***@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 open a working set from that repository.
- Someone else opens a working set from that same repository.
- I make my changes and push them.
- He makes his changes and pushes them.
- I delete my working set.
- He deletes his working set.

No work is lost because the working set and the repository are two different
beasts.

And please, before you dig yourself in deeper with something ridiculous like
"this kind of stuff doesn't happen in practice" keep in mind that I switched
*away* from Mercurial and Darcs precisely *because* such things happened in
practice. (That and sharing repositories with Fossil is a lot easier than
any other system I evaluated ever.) Yes, the problems with Mercurial and
Darcs (and Git and ...) can be worked around by disciplined work flow
control, but in complex or highly active projects it is very easy to make
the kinds of mistakes that lead to loss of data and work.

I'd much rather my tool protect me from this, thank you very much.
Daniel Carrera
2010-01-21 15:08:09 UTC
Permalink
Post by Michael Richter
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.
Michael Richter
2010-01-21 15:25:35 UTC
Permalink
Post by Daniel Carrera
Post by Michael Richter
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*.)
Post by Daniel Carrera
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.
Post by Daniel Carrera
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.
Daniel Carrera
2010-01-21 15:48:49 UTC
Permalink
Post by Michael Richter
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.
Post by Michael Richter
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.
Post by Michael Richter
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.
Post by Michael Richter
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.
Post by Michael Richter
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.
Post by Michael Richter
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.
Twylite
2010-01-21 16:03:38 UTC
Permalink
Hi,
Post by Daniel Carrera
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.
Post by Daniel Carrera
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
Daniel Carrera
2010-01-21 16:41:12 UTC
Permalink
Post by Twylite
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.
a***@mail.com
2010-01-21 17:31:21 UTC
Permalink
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 <***@gmail.com>
To: fossil-***@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-***@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Stephen De Gabrielle
2010-01-21 19:28:34 UTC
Permalink
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.
Post by a***@mail.com
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-----
Sent: Thu, Jan 21, 2010 10:11 pm
Subject: Re: [fossil-users] Add files recursively?
Again, this has absolutely nothing to do with branches. I don't know
where you're getting that idea from.
$ 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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
--
Stephen De Gabrielle
***@acm.org
Telephone +44 (0)20 85670911
Mobile +44 (0)79 85189045
http://www.degabrielle.name/stephen
Daniel Carrera
2010-01-21 19:40:36 UTC
Permalink
Thanks. That really does sound promising.

Daniel.
Post by Stephen De Gabrielle
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.
Post by a***@mail.com
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-----
Sent: Thu, Jan 21, 2010 10:11 pm
Subject: Re: [fossil-users] Add files recursively?
Again, this has absolutely nothing to do with branches. I don't know
where you're getting that idea from.
$ 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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Stephen De Gabrielle
2010-01-21 23:38:35 UTC
Permalink
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 :)
Post by Daniel Carrera
Thanks. That really does sound promising.
Daniel.
Post by Stephen De Gabrielle
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.
Post by a***@mail.com
As I said earlier, I think you misunderstand how the SCMs you criticize
actually work. So you are seeing problems that don't exist.
Post by Stephen De Gabrielle
Post by a***@mail.com
You made very good points. Let's talk once you understand how fossil
actually works...- Altu
Post by Stephen De Gabrielle
Post by a***@mail.com
-----Original Message-----
Sent: Thu, Jan 21, 2010 10:11 pm
Subject: Re: [fossil-users] Add files recursively?
Again, this has absolutely nothing to do with branches. I don't know
where you're getting that idea from.
$ 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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
--
Stephen De Gabrielle
***@acm.org
Telephone +44 (0)20 85670911
Mobile +44 (0)79 85189045
http://www.degabrielle.name/stephen
D. Richard Hipp
2010-01-22 00:54:47 UTC
Permalink
Post by Stephen De Gabrielle
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
***@hwaci.com
Daniel Carrera
2010-01-22 07:37:55 UTC
Permalink
Post by D. Richard Hipp
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.

Daniel Carrera
2010-01-22 07:36:28 UTC
Permalink
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.
Post by Stephen De Gabrielle
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 :)
Thanks. That really does sound promising.
Daniel.
Post by Stephen De Gabrielle
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.
Post by a***@mail.com
As I said earlier, I think you misunderstand how the SCMs you
criticize actually work. So you are seeing problems that don't exist.
Post by Stephen De Gabrielle
Post by a***@mail.com
You made very good points. Let's talk once you understand how
fossil actually works...- Altu
Post by Stephen De Gabrielle
Post by a***@mail.com
-----Original Message-----
Sent: Thu, Jan 21, 2010 10:11 pm
Subject: Re: [fossil-users] Add files recursively?
Again, this has absolutely nothing to do with branches. I
don't know
Post by Stephen De Gabrielle
Post by a***@mail.com
where you're getting that idea from.
$ cd B
$ darcs init
$ darcs pull ../A
I am creating a new branch "B", separate, and independent of A.
Ditto
Post by Stephen De Gabrielle
Post by a***@mail.com
for Hg, Git and Bazaar. As I said earlier, I think you
misunderstand how
Post by Stephen De Gabrielle
Post by a***@mail.com
the SCMs you criticize actually work. So you are seeing problems
that
Post by Stephen De Gabrielle
Post by a***@mail.com
don't exist.
Daniel.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
--
Stephen De Gabrielle
Telephone +44 (0)20 85670911
Mobile +44 (0)79 85189045
http://www.degabrielle.name/stephen
------------------------------------------------------------------------
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Daniel Carrera
2010-01-21 15:27:55 UTC
Permalink
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.
Post by Twylite
Post by Twylite
When you clone A to B, a note is made in B that you cloned from
A. So
Post by Twylite
when you are working in B and you push or pull or sync it knows
that the
Post by Twylite
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.
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'
* file 1 in Remote
Shall I pull this patch? (1/1) [ynWsfvplxdaqjk], or ? for help: a
Finished pulling and applying.
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'
* file 1 in Remote
Shall I pull this patch? (1/2) [ynWsfvplxdaqjk], or ? for help: a
Finished pulling and applying.
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
removed `A/1'
removed `A/_darcs/tentative_pristine'
removed
`A/_darcs/patches/0000000115-3cd043376a21c461f8605abb2a579f58ff2419e37248c357425a3a143a9d6ecb'
removed `A/_darcs/patches/pending'
removed
`A/_darcs/patches/0000000110-b044ffccac260b63c9f0f4d92b1c5b85e4221128a9ddf37c12a36415a8d2bdd4'
removed `A/_darcs/patches/pending.tentative'
removed directory: `A/_darcs/patches'
removed
`A/_darcs/inventories/0000000187-198d8c81582fe412f44f446a65a8e40b3b1267107a3e6e72ad2b50a27dbd67e9'
removed
`A/_darcs/inventories/0000000369-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/0000000168-cdb7d192d528a5ab1468b5d4339004ddf47442b6bd2d2e2a6f3ba38c724c0883'
removed `A/_darcs/pristine.hashed/da39a3ee5e6b4b0d3255bfef95601890afd80709'
removed
`A/_darcs/pristine.hashed/0000000000-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
removed
`A/_darcs/pristine.hashed/0000000084-555aaf4b6798d05de804c5dd6de6d1707fece5d5d1dcc9dd34c3834e55058b1e'
removed directory: `A/_darcs/pristine.hashed'
removed directory: `A/_darcs'
removed `A/2'
removed directory: `A'
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.
* 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
* 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 open a working set from that repository.
* Someone else opens a working set from that same repository.
* I make my changes and push them.
* He makes his changes and pushes them.
* I delete my working set.
* He deletes his working set.
No work is lost because the working set and the repository are two
different beasts.
And please, before you dig yourself in deeper with something ridiculous
like "this kind of stuff doesn't happen in practice" keep in mind that I
switched *away* from Mercurial and Darcs precisely *because* such things
happened in practice. (That and sharing repositories with Fossil is a
lot easier than any other system I evaluated ever.) Yes, the problems
with Mercurial and Darcs (and Git and ...) can be worked around by
disciplined work flow control, but in complex or highly active projects
it is very easy to make the kinds of mistakes that lead to loss of data
and work.
I'd much rather my tool protect me from this, thank you very much.
------------------------------------------------------------------------
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Twylite
2010-01-21 13:28:55 UTC
Permalink
Hi,
Post by Daniel Carrera
Post by Twylite
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.
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?
Post by Daniel Carrera
Post by Twylite
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.
Post by Twylite
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.
You are confusing relationships between repositories, relationships
between a working set and a repository, and branches.

What I described doesn't involve branches at all.

When you clone A to B you have not branched anything. You have created
a copy of the repository. That is all.

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. 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).

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. You haven't lost any data from B. The full
repository, including all of A (at the time of cloning or up to the last
pull) is within B. But the tools that work on B don't know what to talk
to when you try to push or pull, because they expected to talk to A and
now A is missing.

Branching cannot happen until you actually commit a change into a
repository. So, if you did make changes on HEAD in B, and committed,
and pushed, then either:
(1) There have been no changes to HEAD on A since you cloned/pulled to
B, in which case the changes are pushed into HEAD on A; OR
(2) There have been changes to HEAD on A, and when sync'ing with B this
creates a branch.

In the numbered points about A is the default parent repository of B.
Substitute A with any other repository if you tell B explicitly to
push/pull/sync with another repository.
Post by Daniel Carrera
Post by Twylite
Then they muck with hardlinks and copy-on-write to try and conserve
disk space and improve performance. (You don't want to use these on
a FAT32 filesystem)
Some muck with hard links, others don't. AFAIK it is Hg that uses hard
links.
Hg and Bazaar use hard links. If you don't use hard links then you have
to actually duplicate the file, which consumes time and space.

Regards,
Twylite
Daniel Carrera
2010-01-21 15:19:52 UTC
Permalink
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Post by Twylite
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.
Daniel Carrera
2010-01-21 12:40:35 UTC
Permalink
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.
Twylite
2010-01-21 13:59:52 UTC
Permalink
Hi,
Post by Daniel Carrera
Wait... I just re-read your post. Tell me if I'm right. Your whole
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
Daniel Carrera
1970-01-01 00:00:00 UTC
Permalink
This works in Windows, too, using junctions instead of symlinks.

-Clark



----- Original Message ----
From: Daniel Carrera <***@gmail.com>
To: fossil-***@lists.fossil-scm.org
Sent: Wed, January 20, 2010 2:37:09 PM
Subject: Re: [fossil-users] Add files recursively?
Post by D. Richard Hipp
__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.
Continue reading on narkive:
Loading...