I imagined some of those scenarios right away after my experiment... Some are great... Until today, I was doing a fossil clone file:// or ssh:// ... Now I can deal with just a single copy of the repo.
I only see it quickly and indirectly mentioned in section 2.3 here: http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki But the text in there doesn't tease me to try new things not available in other VCS. Plus, is kinda hidden, so it ain't obvious you can do it that way. Is it possible to do describe it somewhere for future reference? PS: after running my quick test in fossil 1.31, I ended with two separate artifacts, both on trunk, but without a common ancestor. I'm running Ubuntu, and I haven't compiled the 1.32. I believe that version was released as a patch for this common ancestor issue. Will my test behave differently on 1.32? On Thu, Mar 19, 2015 at 10:57 PM, Richard Hipp <d...@sqlite.org> wrote: > On 3/19/15, Abilio Marques <abili...@gmail.com> wrote: > > After reading Mr. Hipp answer to some previous email about git saying: > > > > So the staging area is being used as a way of working around the fact > > that Git does not allow multiple independent check-outs against the > > same repository? Am I understanding that correctly? > > > > I started to think: what does it mean to have "multiple independent > > check-outs"? And I knew I wouldn't be able to sleep well because of not > > knowing. So I created a new test repo, and began: > > > > mkdir test > > cd test > > fossil new test.fossil > > mkdir a b > > cd a > > fossil open ../test.fossil > > echo "file a" > a.txt > > cd .. > > cd b > > fossil open ../test.fossil > > echo "file b" > b.txt > > cd .. > > fossil status # replied not within an open checkout > > > > Then went to commit in each subdirectory... then did a status... both > > reflected the check-ins in the correct order... and the other directories > > weren't there. Actually going to a (the first commited one) and running > > fossil update trunk did: > > > > ADD b.txt > > REMOVE a.txt > > > > So far seems magic, as I don't seem to grasp the power, uses and > > implications for it. Is there any documentation? This is my first > approach > > to what Mr. Hipp said. Am I mistaken? > > > > You are doing it right. > > There is no documentation because I could not conceive of wanting to > use a VCS in any other way. > > Scenario: You want to compare the performance of two different > versions of the project. So you do two simultaneous checkouts, in > separate directories, and run speed tests on each. > > Scenario: You in the middle of a big change when a support request > from a customer comes in that requires you to work on a release from a > year ago. No need to "stash" all the changes you are in the middle > of, just open the older version in a separate directory - make changes > there and branch it if necessary, then go back to what you were doing. > > Scenario: Do simultaneous builds with different compile-time options > for the same version of the code in three separate directories. > > Scenario: Work on four separate branches, all at the same time, > located in four separate directories. > > Scenario: Be editing code in a branch while simultaneously running a > bisect is on trunk. > > And so forth.... > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > 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
