Re: [fossil-users] symlinks (was Re: xkcd on git)

[Joan Picanyol i Puig]

* Stephan Beal  [20151105 08:09]:
> On Tue, Nov 3, 2015 at 7:59 PM, David Mason  wrote:
> 
> >
> > It's simple: a symlink is a filesystem artifact and should be reflected as
> > such in the repository.  It should not be followed; if foo is a symlink and
> > I say "fs add foo/bar" it should probably give an error. (This might
> > surprise people the first time, but it's easy to explain - foo/bar isn't
> > part of the repo, regardless of where foo points.)
> >
> 
> But it's not quite that simple, philosophically speaking: we expect Fossil
> to extract _exactly_ what we put in it, and that's not portably possible
> when it comes to symlinks. As soon as someone checks out your repo on a
> non-Unix system, fossil is creating output which you did not put in fossil.
> That's a tremendous psychological/philosophical hurdle for me. i'd rather
> live without symlinks than know that my repos check out differently
> depending on the platform.

Then request for a setting the precludes checking symlinks in.

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Joan Picanyol i Puig]

* Ramon Ribó ram...@compassis.com [20150320 11:19]:
 A possible workflow to do partial commits in fossil could be:
 
 - fossil diff --tk --partial-commit
 
 (A special version of fossil diff --tk appears where there is a
 checkbox in every difference)
 
 - Select some differences
 

This is pretty much what hg GUIs (tortoisehg) do, and it is something
rather useful.

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Index (was Re: git-fossil-git does not obtain the same commit hashes.)

[Joan Picanyol i Puig]

* Joel Bruick j...@joelface.com [20140606 06:55]:
 Richard Hipp wrote:
 On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com 
 mailto:n...@cryptonector.com wrote:
 
 On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com
 mailto:estifo...@gmail.com wrote:
  foo.txt has changes A, B, C and D.
 
  After each change the developer had the foresight to do a
 fossil stash
  snapshot. Now the developer decides to put changes B and D into
 branch b-d
  and keep changes A and C on the trunk:
 
 Ah, foresight.  I should be blessed, but I am not, for that that's not
 how I work.
 
 
 I have different reasons for opposing the ability to checking 
 individual lines of a file, and I'd like to get Nico's feedback:
 
 The reason you should never do a partial check-in of a file is because 
 you clearly have not tested that partial change.  And you should 
 always test your code before you commit.  Especially when committing 
 to trunk.
 
 I agree with this, but Git does make testing your staged changes 
 relatively easy. You can call git stash save --keep-index to stash 
 only your unstaged changes, run your tests, commit, then call git stash 
 pop and continue working.
 
 With that said, I think that adding a way to stash partial changes to 
 files would be enough for what most people actually need from a staging 
 area (pulling out unrelated changes so they can be committed separately).

Seconded, this would simplify certain workflows a lot (the painful
alternative has already been pointed out). A command line implementation
of what tortoisehg offers as shelve would be awesome.

keep up the good work
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Possible bug.

[Joan Picanyol i Puig]

* John Found johnfo...@evrocom.net [20130226 21:14]:
 This question on stackoverflow maybe needs some attention: 
 http://stackoverflow.com/questions/13787801/how-to-do-fossil-commands-on-relative-directory/14642028#14642028
 
 My experiments indicates some problems, but for me is not clear is it a bug 
 or intended behavior.

Known issue.

http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04760.html
http://fossil-scm.org/index.html/tktview?name=ee97701f4c

I currently use the trick of symlinking / from a working directory, it
works for me. I'm unsure how it interacts with the symlink-related
settings.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Latest stable release or dev release does not compile with option: --static

[Joan Picanyol i Puig]

* Richard Hipp d...@sqlite.org [20130130 19:31]:
 On Wed, Jan 30, 2013 at 12:30 PM, K. Fossil user 
 ticketpersonnal-fos...@yahoo.fr wrote:
 
  People would like to use a DVCS everywhere with any distro with the SAME
  binary, not the one specific to a distro.
 
 
 
 I concur.  Unfortunately, this is a function of the distro more than of the
 application.  For example, OpenSSL seems to not support static linking and
 is also highly distro-dependent, so a universal binary needs to omit HTTPS
 support.  So there are tradeoffs.
 
 Fossil has traditionally worked great on all systems, directly from
 sources.  And the binaries are highly portable (module OpenSSL issues).
 Have you seen otherwise?

Since no one has mentioned them yet, I wonder if using
dropbear/libtomcrypt would be an option?

https://matt.ucc.asn.au/dropbear/dropbear.html
http://libtom.org/?page=featuresnewsitems=5whatfile=crypt

There's also polarSSL (previously xyssl), but licensing issues should be
considered: https://polarssl.org/foss-license-exception
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] why does `fossil rm' not do the real thing?

[Joan Picanyol i Puig]

* Richard Hipp d...@sqlite.org [20121213 16:37]:
 
 My current leanings are to change rm and mv as follows:

[...]
 
 It seems to me that the behaviors above are the most intuitive and
 provide developers with the least amount of surprise.

I agree.

Regarding your later post, I fail to see how this proposed behaviour
encourages VCS-as-backup sloppiness.

qvb
-- 
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] howto `grep' through old revisions

[Joan Picanyol i Puig]

* Gilles gilles.gana...@free.fr [20121124 23:01]:
 On Sat, 24 Nov 2012 09:21:54 -0500, Richard Hipp
 d...@sqlite.org wrote:
 One big problem here is that the user will doubtless expect to have full
 Perl regular expressions.  That will mean another compile-time dependency.
 And maybe also a run-time dependency if a shared library is used (as most
 distribution packages managers will likely require).  Suddenly, Fossil
 becomes much less stand-alone and self-contained.
 
 Does someone know of a good LGPL regex library that could easily be
 statically compiled in the Fossil binary?
 
 http://en.wikipedia.org/wiki/Comparison_of_regular_expression_engines#Libraries

tre?

http://laurikari.net/tre/about/

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] suggestion

[Joan Picanyol i Puig]

* Richard Hipp d...@sqlite.org [20121120 01:13]:
 On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff 
 veedeeh...@googlemail.comwrote:
 
  -- fossil timeline: I find this really hard to read and use for at least
  two reasons:
 
 
 I seldom use fossil timeline, preferring instead to run fossil ui and
 look at the timeline with the graph in my web-browser.  Am I the only one
 that thinks this way?

Well, I use fossil in many places where I can't easily use fossil ui
(no graphic environment). Even when if available, I tend to use it only
because I've yet ito find out how to quickly go from fossil timeline to
let me see how file F changed in changeset C in the command line.

I'd suggest an option to include more vertical space, even if it breaks
the current one-line-per-commit paradigm. Also, an option as in hg log
--patch -r 123 (show me the patch corresponding to that version)

 
 
  -- the `fossil diff --from rev1 --to rev2' syntax deviates from the much
  more common (and easier to type `-r rev1:rev2') for no good reason I can
  see.
 
 
 You think that -r rev1:rev2 is more intuitive than --from rev1 --to
 rev2?  Really?  If it's important, we could add it as alternative syntax,
 I suppose.  But what would you do if the name of rev1 contained an embedded
 colon?  Do we have to invent some kind of escape syntax to accompany this
 notation?

No more intuitive, but shorter and more standard. Instead of an escape
syntax, I understand that forbidding ':' from branch names would
suffice?

thanks
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Problem on website with non-root repository

[Joan Picanyol i Puig]

* Richard Hipp d...@sqlite.org [20120916 20:06]:
 On Sun, Sep 16, 2012 at 1:57 PM, Gautier DI FOLCO gautier.difo...@gmail.com
  wrote:
 
  Hi all,
 
  I have multiple repositories on a server which hosts other things (like
  internal tools accessible via a web browser, etc.), so I setup nginx with
  the reverse proxy module, my fossil server is accessible via /fossil/, but
  all media, css, etc. are seeked at /, they are not founded, is their a
  place
  to set the root of the server is this a lack/bug ?
 
 
 Fossil goes off of the HOST: field in the HTTP header.  Can you configure
 nginx to set the HOST: field appropriately on the inbound HTTP request?

This sounds like a peculiar reading of RFC 2616...

14.23 Host

The Host request-header field specifies the Internet host and port
number of the resource being requested, as obtained from the
original URI given by the user or referring resource (generally an
HTTP URL, as described in section 3.2.2). The Host field value MUST
represent the naming authority of the origin server or gateway given
by the original URL. 

Isn't PATH_INFO meant for this?

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] The future of markdown-in-fossil

[Joan Picanyol i Puig]

* Stephan Beal sgb...@googlemail.com [20120803 15:34]:
 
 Another consideration here is that the wiki has kind of fallen out of use,
 with the embedded docs system generally being preferred. While i admit that
 i pay a good deal of attention to fossil's wiki API (i've added several of
 the wiki subcommands and the wiki API was amongst the first of the JSON
 APIs added), i will admit that embedded docs are generally a better
 solution. But the wiki is just too convenient (which is the only reason
 anyone really uses a wiki, anyway). Once i get embedded docs support in the
 JSON API, i probably won't touch the wiki API again.

I believe you are underestimating the built-in wiki. As I see it is one
of fossil's killer features: my use case is a dramatically lower barrier
to entry for non-developers contributing to a non-distributed repo.

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Postmortum: DRH in Munich

[Joan Picanyol i Puig]

Short on time, just a few terse comments.

* Stephan Beal sgb...@googlemail.com [20120703 21:37]:
 - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor.
 We looked closely at this and it this will not be nearly as much work as i
 first anticipated, but we will have to munge the output just a tiny bit to
 suit or needs.

Sounds great, as long as it is not a requirement (either in fossil nor
in the client). I guess the wiki markup issue is a done deal then?

 - Adding more metadata to wikis, e.g. a title field. We might embed this
 into the wiki content using a new wiki tag or similar.

This would be great if it enabled keyword based tagging for later
search.

 We will have to enable the style attribute on tags in the wiki
 content (style is currently filtered out by the wiki out of safety
 concerns), and if anyone can name a concrete security reason why that
 would be a Bad Idea, please speak up!

This sounds like a wide open door for XSS attacks. 
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values

 - Adding a system for integrating custom pages to fossil repos, e.g.
 /myCustomPage, which would call content stored in the db. The original idea
 was to use this as a new layout mechanism for the site, but we think that
 this could possibly be used to reimplement some of the current static
 pages . Part of this would include a templating mechanism. The pages could
 have security restrictions and could be flagged as syncable/clonable (or
 not) by the site admin (only admin users would be able to create/edit such
 pages). A logical extension of this would be to build up snippets/widgets
 which users can use to customize their pages (e.g. embedding a
 mini-timeline overview in their home page).

I smell AOLServer...

keep up the good work
-- 
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Newbie question about basics of using fossil

[Joan Picanyol i Puig]

[attempting to regroup subthreads]

[if short on time, please skim to the end to comment on the design]

* Martin Gagnon eme...@gmail.com [20120607 12:06]:
 Le 2012-06-07 à 05:30, Joan Picanyol i Puig lists-fos...@biaix.org a écrit :
  * Andrew Stuart andrew.stu...@supercoders.com.au [20120531 16:15]:
  There are source code files and also operating system configuration
  files.
  
  I would keep two different repositories. For the second one, see below.
  
  I use sudo to edit these files as most of the files are editable only  
  by root.

[...]

  Needless to say, I'd encourage you to share your findings for the
  fossil as a SCM for OS configuration use case.
 
 For file from '/': look this thread:
 
 http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg05576.html
 
 Fossil isn't usable from '/' dir. as a checkout. Some commands
 sometimes work, most of them doesn't. So for system config. I end up
 working on a checkout somewhere in a subdir in my home and I have a
 script which copy file that have changed from '/' to my checkout.
 ('fossil ls' is useful here)

I did save your message from that thread, but ruby  meld are
incompatible with my minimal depencies policy. Also, sudo does have
its own issues and is not available in several scenarios.

* Stephan Beal sgb...@googlemail.com [20120607 12:04]:
 On Thu, Jun 7, 2012 at 11:30 AM, Joan Picanyol i Puig 
 lists-fos...@biaix.org wrote:
 
  * Andrew Stuart andrew.stu...@supercoders.com.au [20120531 16:15]:
   There are source code files and also operating system configuration
   files.
 
  I would keep two different repositories. For the second one, see below.
 
 And i would go one step further and NOT use fossil for the system files.

I would consider being able to use fossil for this a step further :)

 Fossil does not support file permissions other than the +x bit

But this can be just a missing feature, from
http://www.fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki :

The optional 3rd argument defines any special access permissions
associated with the file. The only special code currently defined is
x which means that the file is executable. All files are always
readable and writable.

 and does not understand user/group ownership. Without that, using it
 for managing system-level files is a disaster waiting to happen.  If
 certain files do not have exactly the right permissions... kaboom.

pre-commit/post-update hooks could be used to work around this issue.
See below regarding your use tags for tracking permissions proposal.

 The repo file itself needs to live somewhere outside of the source tree.

I'm not convinced this is true, in fact I believe I've had the repo at
the root of the checkout some times.

 Why not just do everything from the root dir? Chicken-egg - the repo
 file will then live under the directory which it controls (this is
 considered [by myself to be] bad practice).

fossil will ignore the repo file if you don't add it.

 Fossil is not the right tool for that job.

I'd certainly like it to be.

* Martin Gagnon eme...@gmail.com [20120607 12:32]:
 may be storing the output of: ls -ln $(fossil ls)   in the
 repo could be used from a script to check/restore permissions...

uids (or SIDs in Windows) might not be constant among diferents systems.
I believe the uid-uname mapping should be preserved on commit and
require a command line override if it differs on checkout

* Stephan Beal sgb...@googlemail.com [20120607 13:29]:
 Permissions are a touchy subject because they're inherently
 platform-specific and fossil tries to be platform-agnostic insofar as is
 feasible. Once fossil has Unix permissions support, people will want
 extended attributes support, ACLs, and other weird stuff (not that Unix
 permissions aren't weird, but they are the most common case).

I believe the (basic) Unix permission model can be easily supported in
post-NT-Windows. 

* Stephan Beal sgb...@googlemail.com [20120607 13:38]:
 i think tags (which are key/value pairs in fossil) could be used for
 this if we would extend them to be able to tag arbitrary artifact
 types (i seem to recall, possibly incorrectly, that we can only tag
 commits right now?). e.g. tag unix-perms=0754.

That could be a good idea, but the file format does not seem to be
easily extended to support tagging File cards, since Tags are a card
in the manifest as well. I believe it is much easier to extend de File
card specification in a backward compatible way by specifying a 3 digit
special code to mean this permissions as defined by chmod(). Extend it
still further to preserve uid-login.

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] notes compiling on HP/UX

[Joan Picanyol i Puig]

Hi,

Hope it helps someone:

1. Make: Must be a separator on rules line 42.  Stop.

[wsp06] mng:/home/mng/wd $ diff -r
fossil-src-20120317175325/Makefile fossil-src-20120317175325.ok/Makefile
42c42
 TCC +=-I../zlib-1.2.6   -g -O2 -DHAVE_AUTOCONFIG_H
---
 TCC = -cc -I../zlib-1.2.6   -DHAVE_AUTOCONFIG_H

2. (Bundled) cc: error 1914: bad form for `-t' option

Apparently, the link command line is too long. The solution is
to add all the objects to be linked to a file and invoke the
linker like:

ld -o fossil -c ldopts -L../zlib-1.2.6  -lz -lssl -lcrypto

No tcl no test though :(

[wsp06] mng:/home/mng/wd/fossil-src-20120317175325.ok $
autosetup/jimsh0 ./src/../test/tester.tcl fossil
Runtime Error: ./src/../test/tester.tcl:26: Not implemented
at file ./src/../test/tester.tcl, line 26

qvb
-- 
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)

[Joan Picanyol i Puig]

Hi,

Many thanks for your answers, it turns out I got extremely confused by
not paying enough attention to a fossil warning.

* Richard Hipp d...@sqlite.org [20110719 00:52]:
 On Mon, Jul 18, 2011 at 6:41 PM, Joan Picanyol i Puig 
 lists-fos...@biaix.org wrote:
 
  I've stumbled upon a situation in which fossil's latest wins merge
  strategy and a system's far-in-the-future clock have messed up my
  content  timeline. I do recall fossil's warning regarding out-of-synch
  clocks when synching, but thought that it would DTRT since the files
  being modified in that system where unrelated to the files being
  modified in the server against which it was synching.
 
 
 I don't really understand your problem.  I get the part about you having
 make some check-ins with far-in-the-future timestamps.  But Fossil doesn't
 have a latest wins merge strategy.  So I'm not sure where that is causing
 a problem.

latest wins merge strategy has shown to be a poor word choice: I did
not invoke 'fossil merge' at all (I haven't branched). All work was done
in the same (and only) branch, just on diferent systems with out-of-sync
clocks.

 When you try to reference a check-in by its branch name, Fossil actually
 chooses the check-in of that branch with the latest timestamp.  So, if you
 have some check-ins which are far in the future, those check-ins might be
 selected when you use the branch name, even though they are not the last
 check-ins in sequence.  Is that what you are having problems with?  (That
 has nothing to do with merging, though, which is why I don't really
 understand the problem.)

This might indeed be the issue, what surprised me is that fossil
couldn't DTRT.

When I refered to concrete artifacts/manifests I was referencing them by
their hash in 'fossil diff --from x --to y'.

 Another solution is to use the edit feature of the web interface to
 manually change the timestamps of the far-in-the-future check-ins to
 something more reasonable.

Wow! Talk about rewriting history :p

This did the trick: the timeline looks back to normal *and* the content
as shown through the embedded doc URL is the same as on the
filesystem.

* Ron Wilson ronw.m...@gmail.com [20110719 02:10]:
 I think what Joan is refering to is this, from the Fossil documentation:
 
 Wiki pages can branch and merge just like check-ins, though as of
 this writing (2008-07-29) there is no mechanism in the user interface
 to support branching and merging. The current implementation of the
 wiki shows the version of the wiki page that has the most recent
 timestamp.
 
 So I think that manually fixing the timestamps will correct the problem.

Indeed, manually fixing the timestamps has corrected the problem. I
believe the lesson learned (for me) is that embedded doc is not part
of the version graph.

However, the fact that a file is different on the filesystem than
through the web interface I believe should be considered a bug, it is
way too confusing.

tks, and keep up the good work
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Converting from mercurial

[Joan Picanyol i Puig]

* Jeremy Anderson jere...@gmail.com [20110719 06:18]:
 Out of curiosity, why are you converting from mercurial?

1) plain C, single binary
2) integrated wiki  ticketing

The big minus for me which still keeps me on mercurial for some stuff is
the lack of hooks for significant events (commit/update, push/pull).

qvb
--
pica

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)

[Joan Picanyol i Puig]

* Ron Wilson ronw.m...@gmail.com [20110719 14:28]:
 On Tue, Jul 19, 2011 at 4:50 AM, Joan Picanyol i Puig
 lists-fos...@biaix.org wrote:
  Many thanks for your answers, it turns out I got extremely confused by
  not paying enough attention to a fossil warning.
 
 Did Fossil give a warning about the times between the 2 PCs not being in sync?

I can't recall exactly what it said, but I'm pretty sure fossil told me
something to that effect.

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)

[Joan Picanyol i Puig]

Hi,

I've stumbled upon a situation in which fossil's latest wins merge
strategy and a system's far-in-the-future clock have messed up my
content  timeline. I do recall fossil's warning regarding out-of-synch
clocks when synching, but thought that it would DTRT since the files
being modified in that system where unrelated to the files being
modified in the server against which it was synching.

I can live with the weird-looking timeline, but I'd like to get my
content back.

No amount of synching  updating will get the file's contents to be the
same in the filesystem as they are through the embedded doc link which
means that I can't reapply the patch (since on the filesystem the file
is OK), but I can't see it's content either (since fossil hides it from
me, I assume because it consideres it merged). 'fossil changes' does
not show any change.

I can pinpoint the check-in manifest that consists of *only* the diff
I'd like to re-apply, and the artifacts representing the file before and
after the change, but I still don't know how to fix this.

Is this expected? Any ideas?

tks
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil usage in root directory (was Re: [newbie] Can't get started)

[Joan Picanyol i Puig]

Hi,

Thanks for the discussion, it looks that there's some interest in it.
For the record, I'm currently using mercurial + mtree, but I'd like to
avoid the dependency on Python  FreeBSD.

* Stephan Beal sgb...@googlemail.com [20110525 17:25]:
 
 System-level config files often need to belong to a specific user and/or
 group. So fossil would also have to track user names, and there is no
 guaranty that user 'stephan' on host1 is actually the same user as 'stephan'
 on host2 (though they tend to be the same person on my systems ;).
 Philosophically, i don't think that problem can be solved generically.

It is certainly not easy (think LDAP/AD deployments), but fossil is
missing another crucial feature: pre/post-commit hooks.

 Even if fossil did support storing/restoring the whole permissions (with
 user/group names/IDs), it literally couldn't work for anyone but the root
 user: Unix systems won't let a user's process chown a file to a different
 user.

Obviously the OS user running fossil needs apropriate permissions. Given
that though, and assuming fossil grows the ability to track them,
there's no reason why it should not be able to restore them.

 And what to do on files imported into fossil from Windows and checked out on
 Unix systems?

Regarding ownership, I believe the best that can be done is store a
id/name pair on chekin and warn if the mapping does not resolve the same
on checkout.

* Stephan Beal sgb...@googlemail.com [20110525 19:28]:
 On Wed, May 25, 2011 at 7:35 PM, Bill Burdick bill.burd...@gmail.comwrote:
 
  Etckeeper is a specialized tool that uses DVCSes for versioning.  It's OK
  that Fossil can't support everything needed for this, but I don't think it's
  unreasonable for Joan to ask whether Fossil can be used for it -- every
  major DVCS can, except for Fossil.
 
 My apologies - it wasn't my intention to imply that it's not a reasonable
 usage/feature, i was just pointing out reasons it won't work well out of the
 box, and why supporting such usage probably requires more effort than it
 would seem to on the surface.

The problem is that fossil does not support neither good-enough
ownership/permission tracking nor the flexibility to work around it
before/after commit. 

I hope that fossil grows either (or both :) of these features some time,
even though they are likely not one-liners.

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil usage in root directory (was Re: [newbie] Can't get started)

[Joan Picanyol i Puig]

[thread intentionally broken] 

* Joshua Paine jos...@letterblock.com [20110525 16:21]:
 On 5/25/2011 9:59 AM, Gilles wrote:
  For instance, with the repository file at the root of C:\ (so I can
  add any file below that, even in sub-directories), trying to add
  D:\test.txt triggers the error message: C:\fossil.exe: not within an
  open checkout.

[...] 

 So, yeah, all your repo files have to have a common root. It's by design 
 and can't be worked around except by moving files into a common root. 
 (And check out http://en.wikipedia.org/wiki/NTFS_junction_point)
 
 And you should really think about your entire-c-drive-is-my-working-copy 
 thing. Maybe it makes sense for your use case, but it's at least a very 
 unusual use of fossil.

I beg to differ. 2 users is a lower bound for this use case.

As stated in http://fossil-scm.org/index.html/tktview?name=ee97701f4c , this
severely limits the usability of fossil for system configuration management:
it's not possible to just set ignore-glob='*' and add versioned configuration
files as needed. It's a pity, because fossil's all-in-one approach and its
statically compiled distribution make it an excellent candidate for this use
case.

I understand the reason for the current behaviour, but I believe the a.m.
ticket is a bug (which I don't know how to fix).

qvb
--
pica

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil usage in root directory (was Re: [newbie] Can't get started)

[Joan Picanyol i Puig]

* Stephan Beal sgb...@googlemail.com [20110525 16:52]:
 On Wed, May 25, 2011 at 4:42 PM, Joan Picanyol i Puig 
 lists-fos...@biaix.org wrote:
 
  As stated in http://fossil-scm.org/index.html/tktview?name=ee97701f4c ,
  this
  severely limits the usability of fossil for system configuration
  management:
  it's not possible to just set ignore-glob='*' and add versioned
  configuration
  files as needed. It's a pity, because fossil's all-in-one approach and its
  statically compiled distribution make it an excellent candidate for this
  use
  case.
 
 
 Yes, but fossil's primary purpose is a source control system, not a 100%
 general-purpose SCM (or maybe i'm assuming too much there), and no developer
 puts all his source code under the root directory (possibly another
 incorrect assumption).
 
 On Unix systems, the vast majority of volatile/mutable config data lives
 under /etc or a user's home dir, and one can of course create a fossil
 repo/checkout under /etc. But that brings us to another reason NOT to use
 fossil from your root dir for versioning arbitrary system-level config data:
 fossil does not support full persistence of access rights. It supports the
 +x bit, but Richard only added that (AFAIR) after many people bemoaned
 having to chmod +x their configure scripts after each checkout. Some files
 under, e.g., /etc require specific rights. e.g. Linux does not like it if
 /etc/shadow is world-readable (from what i remember, anyway) and ssh doesn't
 like for some files to be world-readable.

Bummer, I incorrectly assumed that fossil tracked all permissions. It
doesn't seem that doing so would be too hard though:

http://fossil-scm.org/index.html/doc/tip/www/fileformat.wiki

The optional 3rd argument defines any special access permissions
associated with the file. The only special code currently defined is
x which means that the file is executable. All files are always
readable and writable. This can be expressed by w permission if
desired but is optional. The file format might be extended with new
permission letters in the future.

Richard, would you consider such a feature request?

tks
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] tags branches after importing from CVS

[Joan Picanyol i Puig]

Hi,

I've imported a CVS repository, and git-cvsimport converted the HEAD
CVS branch to a master one. Since fossil uses trunk as it's default
branch, I've tried to rename all master tags/properties to trunk. It
has kind-of-worked with awk + xargs, but I forgot the --propagate, so
now I'm trying to get a my last check-in set up so I can start working
(and fossil checkout gives me my latest code by default)

Various combinations of tag add  tag cancel have ended up with
(mispellings and all):

jpicanyol@jpicanyol-desktop:~/wd$ fossil tag list --raw c57a6c30e7
branch=master
branck
branck=trunk
sym-branck=trunk
sym-sym-sym-trunk
sym-sym-trunk
sym-trunk
trunk
jpicanyol@jpicanyol-desktop:~/wd$ fossil tag list c57a6c30e7

I'm not quite sure on the meaning of all of these, and I'm not even sure
how I'd want them to be.

Some clues please?
How is tag cancel supposed to work and how am I supposed verify it?
Where are the magic tags modified by --raw defined?

tks
-- 
pica

p.s.: regarding the wiki-shed, I'd vote for extending the current synta
to allow sub-nesting of lists  some simple heading support.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tags branches after importing from CVS

[Joan Picanyol i Puig]

Uhm,

Via the ui I just saw:

branch cancelled by [7020f3fb3d] on 2011-04-07 15:32:07 
branck cancelled by [200825f86c] on 2011-04-07 15:32:29 
branck=trunk cancelled by [0f89bfc5b1] on 2011-04-07 15:26:16 
brank cancelled by [f86c8555bd] on 2011-04-07 15:32:20 
sym-branck=trunk cancelled by [c1d92a38da] on 2011-04-07 15:26:00 
sym-sym-sym-trunk cancelled by [a75d3427b1] on 2011-04-07 15:24:34 
sym-sym-trunk cancelled by [5ef7ad5557] on 2011-04-07 15:25:38 
sym-trunk cancelled by [60206e9e0d] on 2011-04-07 15:25:21 
trunk cancelled by [58019747433c] on 2011-04-07 15:25:09

Which are my messy attempts to clean up.

So, what should I put at the Add the following new tag name to this
check-in: and Make this check-in the start of a new branch named: to
get later checkings I've done unto the trunk branch? Also, how do I
make the changes propagating ?

tks
--
pica

* Bill Burdick bill.burd...@gmail.com [20110407 17:45]:
 One thing you can do is use fossil ui to view the timeline, see the branch
 diagram, and edit tag names.
 
 
 Bill
 
 
 On Thu, Apr 7, 2011 at 10:28 AM, Joan Picanyol i Puig 
 lists-fos...@biaix.org wrote:
 
  Hi,
 
  I've imported a CVS repository, and git-cvsimport converted the HEAD
  CVS branch to a master one. Since fossil uses trunk as it's default
  branch, I've tried to rename all master tags/properties to trunk. It
  has kind-of-worked with awk + xargs, but I forgot the --propagate, so
  now I'm trying to get a my last check-in set up so I can start working
  (and fossil checkout gives me my latest code by default)
 
  Various combinations of tag add  tag cancel have ended up with
  (mispellings and all):
 
  jpicanyol@jpicanyol-desktop:~/wd$ fossil tag list --raw c57a6c30e7
  branch=master
  branck
  branck=trunk
  sym-branck=trunk
  sym-sym-sym-trunk
  sym-sym-trunk
  sym-trunk
  trunk
  jpicanyol@jpicanyol-desktop:~/wd$ fossil tag list c57a6c30e7
 
  I'm not quite sure on the meaning of all of these, and I'm not even sure
  how I'd want them to be.
 
  Some clues please?
  How is tag cancel supposed to work and how am I supposed verify it?
  Where are the magic tags modified by --raw defined?
 
  tks
  --
  pica
 
  p.s.: regarding the wiki-shed, I'd vote for extending the current synta
  to allow sub-nesting of lists  some simple heading support.
  ___
  fossil-users mailing list
  fossil-users@lists.fossil-scm.org
  http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
 

-- 
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tags branches after importing from CVS

[Joan Picanyol i Puig]

* Joan Picanyol i Puig lists-fos...@biaix.org [20110407 17:28]:
 
 Various combinations of tag add  tag cancel have ended up with
 (mispellings and all):
 
 jpicanyol@jpicanyol-desktop:~/wd$ fossil tag list --raw c57a6c30e7
 branch=master
 branck
 branck=trunk
 sym-branck=trunk
 sym-sym-sym-trunk
 sym-sym-trunk
 sym-trunk
 trunk
 jpicanyol@jpicanyol-desktop:~/wd$ fossil tag list c57a6c30e7
 
 I'm not quite sure on the meaning of all of these, and I'm not even sure
 how I'd want them to be.
 
 Some clues please?

 How is tag cancel supposed to work and how am I supposed verify it?

http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki#ctrl

branch.c has the following comment:

** If tagtype is 2 then the tag is being propagated from an
** ancestor node.  If tagtype is 0 it means a propagating tag is
** being blocked.

 Where are the magic tags modified by --raw defined?

See above. Looking at the source it seems that --raw merely disables
de automatic handling of the sym- prefix for the tagname.

I'm confused on the existance of branch=branchname vs. sym-branchname.
It appears redundant to me...

Meanwhile, I've managed to kind-of-restore my repo after realising that
fossil was happily treating tagname=tagvalue as a tag name.

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users