gmane.comp.version-control.fossil-scm.user

Re: 1.22: Add the ability to run TH1 scripts aftersyncrequests

Joe Mistachkin — 2012-05-24T19:10:23

Tino Lange wrote:

The sync request script may actually be evaluated multiple times for a given
transfer (i.e. commit).  Therefore, you can use it for "commit hooks" as
long
as you check that the latest check-in has changed since the last time you
ran
the commit hooks.

--
Joe Mistachkin

sbs diff alignment problem with internationalcaracter (utf8)

Martin Gagnon — 2012-05-24T13:25:32

Hi,

Small esthetic bug here...

In one of our repository, we have some ".locale" translation files (utf-8
encoded) and have Chinese character in it. When doing sbsdiff from web
interface, like that contain Chinese character are miss-aligned.


See screenshot...

Re: fossil bug - same file created simultaneously in two work areas not merging properly

Leo Razoumov — 2012-05-24T13:07:54

Actually, this situation is known as a two-way-merge
http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Two-way_Merge
and it is helpful in many cases.

--Leo--

1.22: Add the ability to run TH1 scripts after syncrequests

Tino Lange — 2012-05-24T08:25:33

Hi!

1.22 ChangeLog: "Add the ability to run TH1 scripts after sync requests"

I'm a bit lost -- where can I find more infrmation about that new 
feature? Examples? What to do with it? Can I for example use it to have 
some basic commit hooks?

Thanks

Tino

Re: Markdown engine integrated into fossil

Natacha Porté — 2012-05-24T05:51:05

Thanks. At this point I would like to say "apologies accepted", but I
do not want it to sound like a reference to Star Wars, because I do mean
it literally.


If you don't mind, I'd rather have it not named at all.

Due to how it's (still) heavily loaded with negative emotions, I would
like not having to interact with the original project or its repository.
And a name change at this level does involve quite a lot of interaction.

However the code I wrote for fossil is significantly different from the
original, due to the integration of fossil idioms (and I'm willing to
integrate even more, but further idioms would have to be pointed out to
me since I couldn't find them by myself). By the way, you might not like
the formatting of the C code, and that too I'm willing to change upon
request.

I thought it would be dishonest concealment to not mention even once the
name of the original project, since that's where part of the code and
all the design comes from. But I mentioned it only once. Just like the
subject of this thread, the code only talks about a "markdown engine",
without a name.

Would the integration of such code, exactly like it is currently on my
fossil clone, without any other reference to the original project than
the first post of this thread, be acceptable?

If it is not (for example if you really want references to the original
project), then I'd rather we first address all technical issues, to
ensure the code itself really has technical merit to be added, before
proceeding to the painful renaming.


Natacha Porté
_______________________________________________
fossil-users mailing list
fossil-users-RyYwo1q5J+rPvulMB6uEI2D2FQJk+8+b< at >public.gmane.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: fossil bug - same file created simultaneously in two work areas not merging properly

Matt Welland — 2012-05-24T02:55:33



Yes, of course the old data is available and recovery is not hard. The
behavior is still far from ideal in my opinion. You don't drop lines from a
file with no visible hint to the user what data may be missing.

I copied the script and ran it with some additional scenarios to see what
would happen:

1. as test case was provided by Justin
      result: CONFLICT
      no hint inside the file of conflicting data.
      no launch of gui merge tool
      may or may not be easy to merge with gui merge tool

2. with all lines the same but for one
      result: "CONFLICT"
      no hint inside the file of conflicting data
      no launch of gui merge
      very easy to merge with a gui merge tool

3. with one line added at end of file
     result: "CONFLICT"
     no hint inside the file of the potentially missing line
     no launch of gui merge
     gui tools automatically merge these correctly.

4. identical files
     result: "CONFLICT"
     no merge necessary

Every one of these cases is not handled well by fossil and there is no hint
that data was dropped from view. I think a new user will be very confused
by what they see.

The 1st and 2nd case should have the conflict markers and or launch the
merge gui.
The 3rd case should probably be automatically merged with no CONFLICT
warning.
The 4th case should NOT report CONFLICT.

Re: fossil bug - same file created simultaneously in two work areas not merging properly

Justin Gedge — 2012-05-24T02:51:33

viric-V1pClxh5vntBDLzU/O5InQ< at >public.gmane.org
would

YES!!!

This would be helpful.  If fossil is set to use xxdiff [or another utility]
to merge conflicts- it becomes really obvious there is a conflict- and the
resolution can be handled at the time of merge seamlessly.  Even the
conflict markers of a text mode would be usefull because the contents of
both work areas are brought to the forefront.

Using a blank file as a common ancestor and treating this situation as
``one big merge conflict'' would be useful.  It removes steps of undoing
[the merge], forking and merging forks in order to bring the contents
together that were created in two different areas under the same file name.

-jmg

http://lists.fossil-scm.org:8080/pipermail/fossil-users/attachments/20120523/cf80c3d7/attachment.html
_______________________________________________
fossil-users mailing list
fossil-users-RyYwo1q5J+rPvulMB6uEI2D2FQJk+8+b< at >public.gmane.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: fossil bug - same file created simultaneously in two work areas not merging properly

Michael L. Barrow — 2012-05-24T00:25:13


Unless I did something wrong while emulating the tests, the data is not 
"discarded" per se. One can move aside the new version of the file,  
update to get the old version and then manually do the merge.

Was that not your experience?

Re: fossil bug - same file created simultaneously in two work areas not merging properly

Matt Welland — 2012-05-23T23:58:58


Assuming that the work done in both files is important to the authors who
wrote it I'd say yes. The solution for the auto-merge-with-conflict could
be as simple as putting the contents of the one parent above the other with
the usual merge markers. Creating an empty common ancestor file and the
original and merge files would be helpful too as most folks probably rely
on a gui merge tool which can handle this just fine.

Currently it looks to the first person to commit as though their changes
were discarded. The file is marked "MERGED" yet only contains content from
the last person to add. Perhaps not something that will happen very often
but the behavior is clearly wrong.

Matt
-=-


_______________________________________________
fossil-users mailing list
fossil-users-RyYwo1q5J+rPvulMB6uEI2D2FQJk+8+b< at >public.gmane.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: fossil bug - same file created simultaneously in two work areas not merging properly

Richard Hipp — 2012-05-23T22:11:01


In which case, the two files have nothing in common and the whole thing is
one big merge conflict.  Is that really helpful?

Re: fossil bug - same file created simultaneously in two work areas not merging properly

Matt Welland — 2012-05-23T20:34:40


It sounds to me that the "common" ancestor would be an empty file.


_______________________________________________
fossil-users mailing list
fossil-users-RyYwo1q5J+rPvulMB6uEI2D2FQJk+8+b< at >public.gmane.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: fossil bug - same file created simultaneously in two work areas not merging properly

Richard Hipp — 2012-05-23T20:28:33


Thanks for the bug report.  But I think Lluís is right:  There isn't
anything Fossil (or any other DVCS) can do with situation, other than
report the conflict to the user, which Fossil did do according to your
log.  So, unless somebody can suggest something better, I think that the
current behavior is correct.

Re: fossil bug - same file created simultaneously in two work areas not merging properly

Lluís Batlle i Rossell — 2012-05-23T20:23:36

How would fossil merge two files with no base data? What algorithm would do
that?

fossil bug - same file created simultaneously in two work areas not merging properly

Justin Gedge — 2012-05-23T20:16:08

Uncovered a bug.  In this case, two users working in their own fossil work
areas independently created a file with the same name.  Each file is
unique.  Fossil identifies that there is a conflict, but does NOT attempt
to merge the files.  Commands to duplicate issue follow:

-jmg

##Script started on Wed 23 May 2012 10:22:54 AM MST
fossil init test.fossil
    project-id: e3d111bd110a8cfccd49f5fda722dbafb2c05e72
    server-id:  54ac75ed1002c3454a9d574c8848729720f6d867
    admin-user: jmgedge (initial password is "2a508f")
mkdir area{1,2}
cd ./area1/
fossil open ../test.fossil
echo "line1_area1" >> file_a.txt
echo "line2_area1" >> file_a.txt
echo "line3_area1" >> file_a.txt
cd ../area2/
fossil open ../test.fossil
echo "line1_area2" >> file_a.txt
echo "line2_area2" >> file_a.txt
echo "line3_area2" >> file_a.txt
fossil set gmerge 'xxdiff "%original" "%baseline" "%merge" -M "%output"'
cd ../area1/
fossil add file_a.txt
    ADDED  file_a.txt
fossil commit -m "area1 initial commit"
    New_Version: 025b2bc66c831dcb3499e7d6200e2aaa6aa7b0c2
cd ../area2/
fossil add file_a.txt
    ADDED  file_a.txt
fossil update
    CONFLICT file_a.txt
    --------------
    updated-to:   025b2bc66c831dcb3499e7d6200e2aaa6aa7b0c2 2012-05-23
17:26:58 UTC
    ags:         trunk
    comment:      area1 initial commit (user: jmgedge)
    fossil: WARNING: 1 merge conflicts
cat ./file_a.txt
    line1_area2
    line2_area2
    line3_area2
_______________________________________________
fossil-users mailing list
fossil-users-RyYwo1q5J+rPvulMB6uEI2D2FQJk+8+b< at >public.gmane.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: Markdown engine integrated into fossil

Bill Burdick — 2012-05-23T19:31:31

Richard,

I really respect and appreciate your standards and the example you set.
 Also, I like the (almost always) kind way people treat each other on this
list and you set the standard for that, as well.


Thanks,
Bill


On Wed, May 23, 2012 at 2:26 PM, Richard Hipp <drh-CzDROfG0BjIdnm+yROfE0A< at >public.gmane.org> wrote:

_______________________________________________
fossil-users mailing list
fossil-users-RyYwo1q5J+rPvulMB6uEI2D2FQJk+8+b< at >public.gmane.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: Markdown engine integrated into fossil

Richard Hipp — 2012-05-23T19:26:10

On Wed, May 23, 2012 at 1:31 PM, Baptiste Daroussin <
baptiste.daroussin-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


I was initially dubious of this claim, due to fluent style of the author
Natasha writing.  But further investigation, and references sent privately
to me by other on this list (thank you) suggest that I was wrong, and that
Natasha is in fact an innocent victim of fraud and that the name was
actually selected by mischievous (dare I say "perverted") third-party
native English-speaking male.

Therefore, I hereby publicly apologize to Natasha for accusing her of
generating code that is less than beautiful, based solely on the name of
the code.  The code is once again a candidate for incorporation into Fossil.

Nevertheless, though attached by fraud, the name is still inappropriate,
and must be changed before being added to Fossil.

Re: Zip command creates zip files that confuseWindows XP

Richard Hipp — 2012-05-23T18:04:35


Fixing it would probably be very simple, if we knew what was wrong.
Probably there is something in the file header that Fossil generates that
WinXP Explorer does not like or is misinterpreting.  But what exactly is
that something?  Can you do some detective work to try to figure out what
it is about Fossil-generated ZIP archives that WinXP explorer does not
like?  (I don't have a copy of WinXP to experiment with.)

Zip command creates zip files that confuse Windows XP

Pavel Aronsky — 2012-05-23T17:56:09

Has anyone noticed this?

When Explorer of WinXP opens a zip created by fossil zip export,
it shows a zero-sized file for every subfolder in the zip.

Explorer of Win7 does not have this problem, and neither does 7z.
However, would it be possible to fix this annoyance for remaining XP users?

Thanks,
Pavel A.

Re: Markdown engine integrated into fossil

Baptiste Daroussin — 2012-05-23T17:31:43

Maybe the name of the library just don't represent the same for the
author as for you, different culture, etc; but this really have
nothing to do with having a keen eye for beauty.

You should really have a look at the code, it was written far before
the name of the library, and there are no comments of any kind like
you seem to imagine.

This is to bad that this great library is just pushed out because of
an unfortunate name which was chosen for a joke (with references, that
apparently noone from the native english speaking world  get)  and
with out any perverse references in mind.

Please have a look at the code before judging of anything about the
author, just judge the code and work she has done.

You don't even have to name the library on the commit log, just "New
markdown format support for embedded documentation or something like
that".
And if the name is a problem, I'm pretty sure she could easily be
convinced to change the name of the library if someone come with a
better name.

Nothing in the code itself reference libupskirt

regards,
Bapt

Re: Markdown engine integrated into fossil

Richard Hipp — 2012-05-23T17:27:55


My apologies if your conjecture is true, and the use of the term "upskirt"
in the library name was innocent.  Yet, while I am open to evidence to the
contrary, I suspect that in this case the word was used with full knowledge
of its connotations.

But, maybe we could move past this and focus on technical matters?  (And on
creating *beautiful* software.)


The filename was changed ".fslckout" to avoid the word for a kind of body
waste (the exact nature of which is still unknown to me) in Hungarian.  The
old name is still supported for legacy but is undocumented and deprecated.

Re: Markdown engine integrated into fossil

Stephan Beal — 2012-05-23T17:00:26


FWIW, and in Natacha's defense: i'm a native US-English speaker, but i've
been away from the States long enough (going on 15 years) that "the U word"
entered my vocabulary for the first time today. It cannot be expected that
non-native speakers are always up-to-date on English slang.

i vaguely remember Fossil's db file extension being changed from ".fos" to
something else at one point because "fos" is a non-polite word in Polish
(IIRC).