On Wed, 19 Dec 2012 01:04:19 +0100, Martin Gagnon <[email protected]> wrote:
On Tue, Dec 18, 2012 at 6:28 PM, j. v. d. hoff
<[email protected]>wrote:
On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp <[email protected]> wrote:
On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer <[email protected]> wrote:
I don't do that (I keep all my fossil repositories in ~/repos), so
haven't paid close attention to the issues. The big one seems to be
accidentally trying to add the repository to itself. The resulting
checkin never terminates. I also recall problems with Windows
(something else I don't use) where the solution was to move the
repository out of the work space.
Maybe the people who helped solve the problems can comment on this? Or
maybe my skimming of such problems has led me to a false conclusion.
I think all these problems are fixed and that it is safe to keep the
repo
in the check-out directory.
relieved to here that, thanks. are there any other valid arguments
(beyond
matter of taste things like "I want to separate the repo from the
checkout"
and facilitating backups by putting all repos in a single place) which
make
it unwise to keep the repo within the checkout?
Capabilities to work on multiple different checkout associated with
different branch/revision/tag using the same repo file.
Example:
---------------------------------------------
$ mkdir checkout
$ cd checkout
## a checkout for the trunk
$ fossil open ~/repos/a_repo.fossil
...
$ cd ..
$ mkdir checkout_some_branch
$ cd checkout_some_branch
## a checkout for the branch "some_branch" using the same
repo
file.
$ fossil open ~/repos/a_repo.fossil some_branch
---------------------------------------------
That is a killer feature for me. This is impossible to do with git or hg.
Eg. with git, each checkout have to be a different clone with their own
".git" directory which contain the whole history.
OK, I see what you mean, but this wouldn't be important for me AFAICS.
actually I don't see any real advantage of this approach compared to simply
updating to the respective branches in turn in order to work on them.
so (for me) this would fall under the "matter of taste" category (which
still means it's nice that it can be done).
j.
Regards
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
