Re: [fossil-users] Unversioned files.

[Taras Zakharko]

My use case is similar to what Adam describes. I already wrote a mail about 
this some time ago, but as I was absent last month, I couldn’t look at this 
feature in more detail until now. To reiterate, we use Fossil for collaborative 
paper writing. There are a lot of supplementary data that is useful to have 
around in the repository, but which does not need to be versioned (reports, 
current datasets etc.). It would be very useful to us if we had the ability to 
make unversioned files part of the checkout as a per-project option. 

@Richard (or others), how would you estimate the difficulty of adding this 
functionality? If I understand correctly, one would need to add a new field for 
storing the path of the unversioned file as well as logic that writes these 
files on checkout. I assume that no changes would be needed for the sync 
protocol itself? 

Best, 

 Taras



> On 31 Aug 2016, at 02:29, Adam Jensen  wrote:
> 
> On 08/30/2016 02:31 PM, Richard Hipp wrote:
>> A new feature of Fossil (currently unreleased and only available to
>> people who are willing to recompile the code on trunk) is "unversioned
>> files".
>> 
>>https://www.fossil-scm.org/fossil/doc/trunk/www/unvers.wiki
> 
> Hey, cool. This seems like a move in a good direction. I can imagine
> scenarios where some files are relevant to a project, and it would be
> convenient to bundle them into the Fossil database for backup and
> syncing, but saving the change history of those files doesn't really
> make much sense. For example, a project might have an associated SQLite
> database and it might be convenient to have a content .dump of that
> database and possibly a few Session Extension[1] changesets stored in
> the repository (and sync'able).
> 
> [1]: https://www.sqlite.org/sessionintro.html
> 
> In this case, it seems like the ability to check-in, check-out, and
> remove these unversioned files from the repository would be needed (for
> it to make sense). In an example work-flow, perhaps only the most recent
> database .dump would be kept. After a few chagesets are accumulated and
> a new common database state is agreed upon, a new .dump could be
> checked-in and the old dumps and chagesets could be removed (if they're
> no longer needed).
> 
> The current implementation doesn't look like it would support this
> (above) scenario.
> 
> "Unversioned files are not a part of a check-out. Unversioned files are
> intended to be accessible as web pages..."
> 
> ___
> 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

[fossil-users] Fossil does not generate https link prefix

[Taras Zakharko]

Dear all, 

I am serving repositories on our internal server via the Fossil GCI mechanism 
behind Apache2 with SSL. The system is OS X. Everything was running perfectly, 
but today I have updated the OS X Server app to the new version and while 
everything is still running, Fossil now fails to generate the https:// prefixes 
for the links, instead using http://. As a result, security features in the 
modern browser ignore the CSS stylesheets (because there is a protocol 
mismatch). So while pushing, pulling as well as website do work — the later 
looks quite ugly. I was looking for the way to make Fossil generate https:// 
prefix, but I couldn’t find any definite information. 

I am sure that Fossil itself is not to blame, because everything was working 
perfectly before the server upgrade. But maybe someone has encountered a 
similar problem and can point me into a direction where to look. The server 
migration script did change the conf file header from:


  ServerName URL

to


  ServerName https://URL:443 

There were no other changes. Other services (some Rails applications) are 
running without any issues. 

Any ideas?

Best, 

 Taras___
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 CGI mystery: crashing at repositories

[Taras Zakharko]

Yep, this seems to work just fine. 

Thanks!

> From: Richard Hipp
> I do not understand the underlying cause of your problem.  But the latest
> check-in might fix it.

___
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 CGI mystery: crashing at repositories

[Taras Zakharko]

Ok, I have tried to track it down a little bit. I looked around in the code and 
found the ‘debug’ option hidden within the CGI server. The binary crashes 
because the cgi_parameter()  is called with NULL from the 
login_check_credentials(). This appears to happen because the 
login_cookie_name() returns NULL in the first place. 

If the repository has been served with fossil server at least once, login 
cookie name seems to be stored in the database and can be retrieved succesfully.

I clearly don’t understand the Fossil authentication code even remotely enough 
to suggest a fix, but maybe this will give you an idea what might have gone 
wrong here. 

Thanks, 

 Taras
___
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 CGI mystery: crashing at repositories

[Taras Zakharko]

> It shouldn't be crashing.  But I don't have any idea what the problem is.
> Which version of Fossil are you running?  Can you recompile using -g so
> that we get better information in the crash log?

This is the trunk [de17e35bf1] on OS X 10.10, using Apache/2.3.9

I am sure that the binary was already compiled with -g (I have additionally 
added the —fossil-debug when configuring, no idea what that does). However, I 
don’t have much clue about debugging CGI (and a search did not help me much 
either). The crash log is generated by the Apple’s logging tool, there is no 
output from Fossil in there. All I get in the Apache log is ‘End of script 
before headers’. 

Is there a way to tell fossil to write an error log on its own?

Thanks, 

 Taras

___
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 CGI mystery: crashing at repositories

[Taras Zakharko]

Dear all,

I am hosting the Fossil repositories on our server via the CGI scripts (as 
described in fossil documentation). Every repository has its own CGI script 
(for cosmetic reasons). 

When creating a new repository and subsequently trying to access it via CGI, I 
get a crash in fossil. The relevant bit of the crash log is attached after the 
message. If I start the web interface locally (from the server machine) via 
fossil server‚ it works. Now the weird bit — after that initial fossil server 
had started and has been killed, the CGI script works like a charm (note that 
fossil ui does not seem to have the same effect!) 

Am I missing something here?  The local fossil server is run under the same 
user as the CGI process. 

Thanks, 

Taras


Crash log

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x

VM Regions Near 0:
--> 
   __TEXT 000104de1000-000104fad000 [ 1840K] r-x/rwx 
SM=COW  /usr/bin/fossil

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   fossil  0x000104def249 cgi_parameter + 313
1   fossil  0x000104e20f1f 
login_check_credentials + 559
2   fossil  0x000104e625ae home_page + 46
3   fossil  0x000104e26313 process_one_web_page 
+ 1715
4   fossil  0x000104e25c0b cmd_cgi + 1739
5   fossil  0x000104e23ea5 main + 2389
6   libdyld.dylib   0x7fff930e25c9 start + 1
___
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] Feature: merge-command

[Taras Zakharko]

Thanks for the comments! 

I will submit the Contributor’s Agreement ASAP. I was not aware that the 
development list existed, and now that I have registered there, please feel 
free to move the conversation to it. I am not very comfortable about mailing 
lists because its not a tool I use a lot, unfortunately…

— Taras


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

[fossil-users] Feature: merge-command

[Taras Zakharko]

Dear all, 

 Fossil’s built-in merge works very well, but for our workflows (academic 
writing), it would be very useful to merge all differences manually (i.e., 
every difference should be treated as a merge conflict). This allows the PIs to 
keep a clear overview of all the changes and make sure the argumentation in the 
paper stays consistent. So far, the lack of such feature is probably the main 
hurdle in convincing my colleagues to migrate their work to Fossil (right now 
we are using Mercurial, and we are quite unhappy).

 I have looked around in the code and it seems that there were some plans for 
implementing a merge-command setting, which allows one to specify a merge tool 
that will be run instead of the built-in merge function. This is similar to the 
gmerge-command,  but will trigger _every_ time a file is merged. This feature 
was never implemented, so I took some time today to see whether I can get it to 
work. Surprisingly, it went very quickly and without any hiccups — the Fossil 
code is really quite clean and modifying it does not feel like walking on 
minefield (the feeling I had from some other open source projects I tried to 
patch). 

 By design, my implementation can never ‘fail' a merge and does not have any 
special treatment for binary files. This means that the merge-command setting 
does not follow the common rules Fossil has for merging, but there is a good 
reason for that.  It is assumed that if the user opts for using an external 
tool, they generally know what they are doing - e.g. they might have a merge 
tool that can merge some binary files etc.
If the merge tool does not produce an output file, the relevant helper files 
are left in the folder and the user is prompted to merge ‘by hand’.

 I am attaching a patch below. I would be very thankful if Richard would 
consider adding it to Fossil trunk. This would really help us a lot in our 
workflow. 

 Best, 

  Taras

Index: src/db.c
==
--- src/db.c
+++ src/db.c
@@ -2229,10 +2229,11 @@
   { "editor",   0, 32, 0, 0, ""},
   { "empty-dirs",   0, 40, 1, 0, ""},
   { "encoding-glob",0, 40, 1, 0, ""},
   { "gdiff-command",0, 40, 0, 0, "gdiff"   },
   { "gmerge-command",   0, 40, 0, 0, ""},
+  { "merge-command",0, 40, 0, 0, ""},
   { "http-port",0, 16, 0, 0, "8080"},
   { "https-login",  0,  0, 0, 0, "off" },
   { "ignore-glob",  0, 40, 1, 0, ""},
   { "keep-glob",0, 40, 1, 0, ""},
   { "localauth",0,  0, 0, 0, "off" },

Index: src/merge3.c
==
--- src/merge3.c
+++ src/merge3.c
@@ -31,10 +31,13 @@
 /* The minimum of two integers */
 #ifndef min
 #  define min(A,B)  (A0 ){
-  const char *zGMerge;   /* Name of the gmerge command */
+   
+   /* invoke the external merge tool if defined */
+if(rc>0 && zMergeCommand && zMergeCommand[0] ){
+ 
+  char *zOut; /* Temporary output file */
+  char *zCmd; /* Command to invoke */
+  const char *azSubst[8];  /* Strings to be substituted */
 
-  zGMerge = db_get("gmerge-command", 0);
-  if( zGMerge && zGMerge[0] ){
-char *zOut; /* Temporary output file */
-char *zCmd; /* Command to invoke */
-const char *azSubst[8];  /* Strings to be substituted */
+  zOut = file_newname(zV1, "output", 1);
+  azSubst[0] = "%baseline";  azSubst[1] = zPivot;
+  azSubst[2] = "%original";  azSubst[3] = zOrig;
+  azSubst[4] = "%merge"; azSubst[5] = zOther;
+  azSubst[6] = "%output";azSubst[7] = zOut;
+  zCmd = string_subst(zMergeCommand, 8, azSubst);
+  printf("%s\n", zCmd); fflush(stdout);
+  fossil_system(zCmd);
+  if( file_wd_size(zOut)>=0 ){
+blob_read_from_file(pOut, zOut);
+file_delete(zPivot);
+file_delete(zOrig);
+file_delete(zOther);
+file_delete(zOut);
 
-zOut = file_newname(zV1, "output", 1);
-azSubst[0] = "%baseline";  azSubst[1] = zPivot;
-azSubst[2] = "%original";  azSubst[3] = zOrig;
-azSubst[4] = "%merge"; azSubst[5] = zOther;
-azSubst[6] = "%output";azSubst[7] = zOut;
-zCmd = string_subst(zGMerge, 8, azSubst);
-printf("%s\n", zCmd); fflush(stdout);
-fossil_system(zCmd);
-if( file_wd_size(zOut)>=0 ){
-  blob_read_from_file(pOut, zOut);
-  file_delete(zPivot);
-  file_delete(zOrig);
-  file_delete(zOther);
-  file_delete(zOut);
-}
-fossil_free(zCmd);
-fossil_free(zOut);
+rc = 0; 

[fossil-users] Option to always use an external merge tool (merge-command)

[Taras Zakharko]

Dear all, 

 if I understand it correctly, when merging files fossil tries to use its own 
algorithm (the src/merge3.c/blob_merge() function) as good as it can, and 
attempts to fall back to an external merge tool (defined by gmerge-command) if 
it is not happy with the result. 

 For our workflows, it would be interesting to have the ability to always use 
the external merge tool in place of the blob_merge(). We use Fossil for 
collaborative research paper writing and its a good thing to see what changes 
other people did when trying to push your own. 

 I have seen in the description of the merge_3way() function that there are 
plans to introduce a new merge-command setting which would do exactly what I 
need it to do. The change required for this seems quite trivial, but as I don’t 
know how to add new settings to fossil or how to properly ‘panic’, I can’t 
submit a patch for this feature. Maybe someone more competent could have a 
quick glance? 

 Of course, I can trivially modify the merge_3way() function so that is always 
attempts to run gmerge-command first, but I really would like to avoid building 
a custom fossil version for our internal use…

 Thank you!

-- 
Taras

___
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 in a multi-user environment

[Taras Zakharko]

I have found the problem - seems that the fossil version installed on my mac 
was still 1.27 and the user name takeover has been added in 1.28. 
Now it works like a charm and I am very happy!  

Sorry for the noise and thanks again for the quick answers!

— Taras

On 04 Mar 2014, at 21:55 , Stephan Beal wrote:

> That's what the name in the URL does. If you're cloning with a name and it
> does not retain that user name in later sessions, that is a bug (which i
> haven't seen) - please help us figure out why fossil is selecting a
> different name. What platform(s) are you on?


___
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 in a multi-user environment

[Taras Zakharko]

Stephan,  Matt,

 thank you for your quick answers!

> 
> That depends on several factors, several of which another list member will
> hopefully detail for us, but what i can say is if you clone like this:
> 
> fossil clone http://remoteUserName@server/... therepo.fsl
> 
> then pull/push will use that user name from then on out. That's the only
> way i ever clone.

Exactly, but there is still a mismatch between the user doing the push/pull and 
the one doing the commit

> If i'm not mistaken, Max can do this:
> 
> fossil user default MaximillianTest

True, but I can’t really tell my colleagues to do this all the time. They are 
linguists, not programmers.  Also, you usually clone very rarely - if a person 
has to clone a project once per month or so, you can’t really expect them to 
remember 
idiosyncratic steps…

> i don't recall if login group support handles centralizing permissions or
> just passwords. Hopefully someone else can enlighten us.

Na, that’s ok - I can replicate the ’same' users over different repos. An 
option to have a default fossil user on a machine or  honouring the user who is 
used to access the central repository would be very useful. I can probably hack 
it into the fossil source, but 
I would like to avoid having to build my own custom fossil…

> Are you talking about a consistency across fossil features within a single
> repo (one local copy), across all clones of a central copy, or across
> several projects in a single login group?

I think its the closes to the second one (clones of a central copy). Basically, 
I think it makes sense if users are checked when synchronising repositories so 
that a change set cannot be added to the same repository if the committing user 
permissions do not match. I do realise that this opens a big can of worms 
though. For the time being, I’d be really happy with some sort of user-friendly 
option (a per-repository setting maybe?) of setting the admin name of a cloned 
repository to the user who was used to access the original. 

> I'm not sure I understand what exactly is your issue but are you cloning
> via a server or directly from shared disk?

I am cloning via HTTP, my fossil server lives in a virtual machine.  To briefly 
summarise, my issue is that the admin user of the cloned repository is the 
default one instead of the user used to access the repo (e.g. I clone the repo 
as admin@ip and the local admin user is set to ‘taras’ instead, so in the end 
the central version has ‘taras’ as a contributor although the user with this 
name is not even registered in the central repository).  Not a big thing and 
easy to fix with ‘fossil user default’ (as Stephan mentiones above), but can be 
quickly confusing and doing ‘fossil user default' cannot be requested of an 
average non-programmer, who shouldn’t be bothered with such technicalities.  

Thanks,

 Taras
___
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 in a multi-user environment

[Taras Zakharko]

Dear all,

 I am currently looking into the possibility of using Fossil as our next SCM 
(we currently use Mercurial, and while it works, many things could be 
improved).  The task is primarily 
collaborative paper writing in a research institute, most authors are 
non-programmers and thus want the system to be as easy to use as possible (this 
is why Fossil is so interesting). 
Now, I have some problems with setting up a sane multi-user environment. Let me 
briefly go though the most important points:

- there will be potentially a large number of projects
- all projects are private (i.e. invisible to any unauthorised user)
- the users are shared between all projects (the permissions might differ)
- every potential contributor has a different user account

All this seems fairly easy to do, I have a template project with all relevant 
users which can be taken as the base for new repository, with permissions set 
in an appropriate way. However, I have run
into a problem and I can’t seem to find the way to solve it. Briefly, its about 
how Fossil synchronises users and the fact that users and authors of commits 
appear to be different things. When I clone a remote repository 
and push some changes into it, the name of the user will be my local admin name 
and not the name of the user I am actually using to communicate with the 
repository. Imagine the following scenario:

We create a new project and my colleague, Maximilian Test is one of the key 
authors. E.g. the user ‘MaximilianTest' has full authoring permissions for the 
repo. However, at his local machine, his user name is ‘max’
rather than ‘MaximilianTest’ - when he clones the repository and makes some 
changes, we will see the  user ‘max’ in our timeline. Even more confusing when 
he then uses some other machine where the user name is simply ‘user’ or 
‘default’. 
Now, I know that he should have cloned his repository using -A  MaximilianTest 
instead, but it will not happen and I just have to deal with it. With 
Mercurial, there was at least a way to set the default user in the central 
config file, I can’t find such an option with Fossil. 

So basically, two questions: a) is it possible to solve this problem in an easy 
way? To put it bluntly, I want to synchronise the ’user as an author’ and the 
‘user as entity of authorisation’;  b) what is the reasoning behind the current 
design? I though if a system includes users and permissions as a standard 
feature, it would make sense for it to make sure that these are honoured in a 
consistent way across the repository? It seems to me that user is just being 
used to check the access rights for the push/pull, but not actually to verify 
the rights to contribute to the repository. 

Thank you!

— Taras



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