On Thu, Sep 2, 2010 at 9:45 PM, Nolan Darilek <[email protected]>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello. I'm using Fossil on a small project I started recently and it
> seems like an interesting concept. There is one thing about which I'm
> unclear, however.
>
> The reference states that multiple working trees can be tied to a single
> repository. How exactly is this done, and I'm wondering if it is what I
> think it is?
>
> I have a group of tangentially related projects that all use a core
> library and have various interdependencies. Even though they serve
> different niches (core library, web service and mobile app using aspects
> of said core library, etc.) I would still benefit from tracking them
> under a single issue tracker/wiki hierarchy. Sometimes an issue that
> manifests in one app actually originates in the core library. I was
> thinking of doing a multi-project Redmine installation for this but
> never quite set it up, partially because of the trouble and partially
> because I vastly prefer distributed development.
>
> Is that what the multiple working tree support is intended to
> accomplish, or am I very confused about what a working tree means in
> this context? :)
>
I'm not exactly clear on what you read, but I think what was being
communicated is that if you have a single project repository, you can
checkout multiple trees that one repository into different directories of
your local disk. So if your repository is named ~/myrepo.fossil, you might
have three different checkouts at ~/myproj/dev, ~/myproj/testing, and
~/myproj/release. All three checkouts can be of different versions of the
project. Each can update and commit independently of the others. But all
three use the same repository files myproj.fossil.
>
> I'm also wondering if this approach is how wiki pages, issues, etc. are
> versioned such that it's possible to edit the wiki/HTML/CSS as plain text?
>
At this time, tickets and CSS cannot be edited separately - you have to use
the web interface (or if you are ambigious, raw SQL). But to plain-text
edit wiki, first export the original content of the page:
fossil wiki export WikiPageName filename.txt
Then edit filename.txt, then check-in your changes with
fossil wiki commit WikiPageName filename.txt
You can also make wiki, or ASCII text, or HTML, or other kinds of web
content part of your source tree and view it through the web interface.
That's how the entire Fossil website is constructed. (The entire Fossil
website, except for the precompiled-binary download page, is just an
instance of Fossil running on the Fossil self-hosting repository.) See
http://www.fossil-scm.org/fossil/doc/tip/www/embeddeddoc.wiki for additional
information on how to put documentation files in your source tree and make
them available.
Stupid Fossil trick of the day: If you want to see what the Fossil website
looked like on January 1, 2009 (for example) you can go to:
http://www.fossil-scm.org/fossil/doc/2009-01-01/www/index.wiki
Plug in any other date besides 2009-01-01 to see what the website looked
like on that date. You can substitute any other revspec you want in place
of the date. So, to see what the website looked like at the most recent
release, replace the "2009-01-01" with "release". You get the idea...
>
> This looks like an interesting concept. Not sure if I like it yet but
> I'm willing to give it a shot.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyAU0gACgkQIaMjFWMehWJtQgCeLhvPfUvWyc12wiNEOW9ZuvUS
> 6TwAn0bgQ2kSPC5BCpx3+m3iU5P1nM4q
> =NOfi
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
D. Richard Hipp
[email protected]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
