[fossil-users] Bug with fossil flattening tree during a 'fossil mv'

[Michael Barrow]

I wanted to move a directory up in the tree. Notice how fossil flattened the 
html subdir (highlighted in bold). Is this a bug or feature?

Version: [73c24ae363] 2010-03-18 14:20:33 UTC

crazy-arms:Projects $ fossil mv fstc/35c/* 35c/
RENAME Projects/fstc/35c/35c.pl Projects/35c/35c.pl
RENAME Projects/fstc/35c/35c.sql Projects/35c/35c.sql
RENAME Projects/fstc/35c/cornerclient.pl Projects/35c/cornerclient.pl
RENAME Projects/fstc/35c/cornerserver.pl Projects/35c/cornerserver.pl
RENAME Projects/fstc/35c/cornerweb.html Projects/35c/cornerweb.html
RENAME Projects/fstc/35c/cornerweb.pl Projects/35c/cornerweb.pl
RENAME Projects/fstc/35c/html/cie.html Projects/35c/cie.html
RENAME Projects/fstc/35c/html/oc.html Projects/35c/oc.html
RENAME Projects/fstc/35c/html/of.html Projects/35c/of.html
RENAME Projects/fstc/35c/html/oi.html Projects/35c/oi.html
RENAME Projects/fstc/35c/html/on.html Projects/35c/on.html
RENAME Projects/fstc/35c/lastRun.sh Projects/35c/lastRun.sh


--
Michael Barrow
michael at barrow dot me




___
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 rm ./*

[Kohn Bernhard]

Oh no, I didn't meant to say, its important.
And yes, you are right, I use this for an obscure corner case, and doing this 
with commandline is no problem.


Best regards
  Bernhard
___
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] ticket notifications

[Jacek Cała]

Thanks for ideas I'll try to play with this.

  Jacek

2010/6/24 Joshua Paine 

> On 06/24/2010 02:39 PM, Jacek Cała wrote:
> > Regarding tickets notification, it would be nice if opening/closing
> > tickets allow starting/stopping time measurement. In this way fossil
> > could count up how long it takes to complete tasks.
>
> IMO this is way, way out of scope for fossil, but it wouldn't be hard to
> build such reports yourself by reading the fossil db or just checking
> the timeline rss periodically.
>
>  gives you the
> last 200 ticket-related events, and it would be trivial to parse with an
> RSS lib, an XML lib, or just a couple regex.
>
> --
> Joshua Paine
> LetterBlock: Web applications built with joy
> http://letterblock.com/
> 301-576-1920
> ___
> 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

Re: [fossil-users] ticket notifications

[Joshua Paine]

On 06/24/2010 02:39 PM, Jacek Cała wrote:
> Regarding tickets notification, it would be nice if opening/closing
> tickets allow starting/stopping time measurement. In this way fossil
> could count up how long it takes to complete tasks.

IMO this is way, way out of scope for fossil, but it wouldn't be hard to 
build such reports yourself by reading the fossil db or just checking 
the timeline rss periodically.

 gives you the 
last 200 ticket-related events, and it would be trivial to parse with an 
RSS lib, an XML lib, or just a couple regex.

-- 
Joshua Paine
LetterBlock: Web applications built with joy
http://letterblock.com/
301-576-1920
___
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] ticket notifications

[Eric]

> Regarding tickets notification, it would be nice if opening/closing
> tickets
> allow starting/stopping time measurement. In this way fossil could count
> up
> how long it takes to complete tasks. This would be more intentional than
> in
> eclipse's mylyn but still very useful.
>
>   Regards,
>   Jacek
>

Fossil is distributed, so there is no way to do this. Even if there were,
does opening a ticket really mean that someone has started work on it? Are
you perhaps viewing this from the point of view of a one-person
repository?

Regards,

Eric

___
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] ticket notifications

[Ron Aaron]

On Thursday 24 June 2010 21:28:15 Richard Hipp wrote:
> There is nothing in principle that would prevent such functionality from
> being added.  But on the other hand, no such functionality currently exists.

I'm happy using the RSS feed feature to get notifications when things change; I 
suppose if a large number of people used RSS on a particular server it could 
become a resource issue, but that's not my current problem. 

-- 
Sending me something private?
Use my GPG public key: AD29415D


signature.asc
Description: This is a digitally signed message part.
___
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] ticket notifications

[Jacek Cała]

Regarding tickets notification, it would be nice if opening/closing tickets
allow starting/stopping time measurement. In this way fossil could count up
how long it takes to complete tasks. This would be more intentional than in
eclipse's mylyn but still very useful.

  Regards,
  Jacek

2010/6/24 Richard Hipp 

> There is nothing in principle that would prevent such functionality from
> being added.  But on the other hand, no such functionality currently exists.
>
> Notice that the issue is complicated by the fact that ticket changes can
> occur on disconnected systems.  When are the emails sent?  When the
> disconnected system syncs with the server that is doing the emailing,
> perhaps?
>
>
> On Thu, Jun 24, 2010 at 2:18 PM, Jeff Rogers  wrote:
>
>> Hi all,
>>
>> Is there a way to set up the ticket system to send email notifications
>> when a ticket is created (or changed, etc)?  There doesn't appear to be
>> any way in TH1 to run an external command (like sendmail)
>>
>> Alternately, is there a command-line way to list any tickets created in
>> the past X (e.g., 1 day), so that a cronjob could check for new tickets
>> and send mail?
>>
>> Thanks
>> -J
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
>
>
> --
> -
> D. Richard Hipp
> d...@sqlite.org
>
> ___
> 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

Re: [fossil-users] ticket notifications

[Richard Hipp]

There is nothing in principle that would prevent such functionality from
being added.  But on the other hand, no such functionality currently exists.

Notice that the issue is complicated by the fact that ticket changes can
occur on disconnected systems.  When are the emails sent?  When the
disconnected system syncs with the server that is doing the emailing,
perhaps?

On Thu, Jun 24, 2010 at 2:18 PM, Jeff Rogers  wrote:

> Hi all,
>
> Is there a way to set up the ticket system to send email notifications
> when a ticket is created (or changed, etc)?  There doesn't appear to be
> any way in TH1 to run an external command (like sendmail)
>
> Alternately, is there a command-line way to list any tickets created in
> the past X (e.g., 1 day), so that a cronjob could check for new tickets
> and send mail?
>
> Thanks
> -J
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
-
D. Richard Hipp
d...@sqlite.org
___
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 rebase

[Richard Hipp]

I think that after a git-rebase or a fossil-merge, the content of the leaves
of all branches are the same.  The difference is that with git-rebase, you
have rewritten the history of the branch so that whereas in reality
development of the "topic" branch began with version E,

 A---B---C topic
/
   D---E---F---G master


After git-rebase, it appears as if the development of topic began with
version G.

 A'--B'--C' topic
/
   D---E---F---G master

With a fossil-merge, you end up with a new version D which has the same
content as version C' in git:

 A---B---C---D topic
 /
D---E---F---G master

But with fossil, the fact that you started development on version E is
preserved in the history.  (Note that in the ascii-art diagram above I am
not showing the merge from G to D, but that merge is shown on the
timeline-graph in an actual Fossil instance.)

Some people seem cool with the idea of rewriting the history of a project.
Others no so much.  Some commentators have suggested that "git rebase"
should be renamed to "git lie".  The whole idea does seem like something out
of 1984.  (Wasn't Winston Smith's job in that novel to do "rebasing" all
day?)  For me:  I need an unimpeachable audit trail for certain projects and
rebase is not consistent with that.


On Thu, Jun 24, 2010 at 9:20 AM, Michael Richter wrote:

> I'm not a git user, so I have no idea.
>
>
> On 24 June 2010 18:56,  wrote:
>
>> I'm not sure. Is there really no difference?
>>
>> - Altu
>>
>>
>>
>> -Original Message-
>> From: Michael Richter 
>> To: fossil-users@lists.fossil-scm.org
>> Sent: Thu, Jun 24, 2010 4:23 pm
>> Subject: Re: [fossil-users] fossil rebase
>>
>>
>> What does this do that fossil merge trunk from my branch in
>> ttmrichter doesn't do?
>>
>>
>> On 24 June 2010 16:31,   wrote:
>> Well, you have custom changes (A, B, C) in a branch and you want to
>> keep up with latest changes happening in trunk - at frequent intervals.
>>
>> What rebase does is it applies your changes A, B & C to new head (G)
>> with a knowledge of everything that has happened between E & G. If any
>> of A, B or C was pulled in to the trunk, that change will be removed
>> automatically.
>>
>>
>> - Altu
>>
>>
>> -Original Message-
>> From: Eric 
>>
>> To: fossil-users@lists.fossil-scm.org
>> Sent: Thu, Jun 24, 2010 12:00 pm
>> Subject: Re: [fossil-users] fossil rebase
>>
>>
>>
>> > Git rebase help has a very good graphic to explain what it does:>>
>> Assume the following history exists and the current branch is
>> "topic":>>   A---B---C topic>  /> D---E---F---G
>> master>> From this point, the result of either of the following
>> commands:>> git rebase master> git rebase master topic> would be:>>
>>A'--B'--C' topic>  /> D---E---F---G
>> master>> Here, git forgets versions A, B & C if they are not published
>> (tagged).> I agree we don't want fossil to forget anything.>> However,
>> if fossil can do following, that would be very helpful:>>
>> A---B---C topic>/>   /   A'--B'--C' (new name)>
>>   /   /> D---E---F---G trunk>> - Altu>But why would
>> anyone want to do
>> that?E.___fossil-users
>> mailing
>>
>> listfossil-us...@lists.fossil-scm.orghttp://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
>>
>>
>>
>>
>>
>> --
>> "Perhaps people don't believe this, but throughout all of the
>> discussions of entering China our focus has really been what's best for
>> the Chinese people. It's not been about our revenue or profit or
>> whatnot."
>> --Sergey Brin, demonstrating the emptiness of the "don't be evil"
>> mantra.
>>
>>
>> ___fossil-users mailing
>> listfossil-us...@lists.fossil-scm.orghttp://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
>>
>
>
>
> --
> "Perhaps people don't believe this, but throughout all of the discussions
> of entering China our focus has really been what's best for the Chinese
> people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
-
D. Richard Hipp
d...@sqlite.org
_

[fossil-users] ticket notifications

[Jeff Rogers]

Hi all,

Is there a way to set up the ticket system to send email notifications 
when a ticket is created (or changed, etc)?  There doesn't appear to be 
any way in TH1 to run an external command (like sendmail)

Alternately, is there a command-line way to list any tickets created in 
the past X (e.g., 1 day), so that a cronjob could check for new tickets 
and send mail?

Thanks
-J
___
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 rebase

[Eric]

> I'm not sure. Is there really no difference?
>
> - Altu
>
>

I was going to mention the merge too - I think that the resulting leaf
would be the same, but the tree would not have been re-arranged.

 You **do not** change history. The principle is the same as in
accounting, where you should not erase an erroneous entry, you should
reverse it out.

But then I tend to think in terms of Software Configuration Management,
not source control.

Regards,

Eric


>
> -Original Message-
> From: Michael Richter 
> To: fossil-users@lists.fossil-scm.org
> Sent: Thu, Jun 24, 2010 4:23 pm
> Subject: Re: [fossil-users] fossil rebase
>
>
> What does this do that fossil merge trunk from my branch in
> ttmrichter doesn't do?
>
>
> On 24 June 2010 16:31,   wrote:
> Well, you have custom changes (A, B, C) in a branch and you want to
> keep up with latest changes happening in trunk - at frequent intervals.
>
> What rebase does is it applies your changes A, B & C to new head (G)
> with a knowledge of everything that has happened between E & G. If any
> of A, B or C was pulled in to the trunk, that change will be removed
> automatically.
>
>
> - Altu
>
>
> -Original Message-
> From: Eric 
>
> To: fossil-users@lists.fossil-scm.org
> Sent: Thu, Jun 24, 2010 12:00 pm
> Subject: Re: [fossil-users] fossil rebase
>
>
>
>> Git rebase help has a very good graphic to explain what it does:>>
> Assume the following history exists and the current branch is
> "topic":>>           A---B---C topic>          />    
> D---E---F---G
> master>> From this point, the result of either of the following
> commands:>> git rebase master> git rebase master topic> would be:>>
>                A'--B'--C' topic>                  />    
> D---E---F---G
> master>> Here, git forgets versions A, B & C if they are not published
> (tagged).> I agree we don't want fossil to forget anything.>> However,
> if fossil can do following, that would be very helpful:>>
> A---B---C topic>            />           /       A'--B'--C'
> (new name)>
>           /       />     D---E---F---G trunk>> - Altu>But why
> would
> anyone want to do
> that?E.___fossil-users
> mailing
>
> listfossil-us...@lists.fossil-scm.orghttp://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
>
>
>
>
>
> --
> "Perhaps people don't believe this, but throughout all of the
> discussions of entering China our focus has really been what's best for
> the Chinese people. It's not been about our revenue or profit or
> whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil"
> mantra.
>
>
> ___fossil-users mailing
> listfossil-us...@lists.fossil-scm.orghttp://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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil rm ./*

[Jeff Rogers]

Kohn Bernhard wrote:
> Hello all,
> 
>  
> 
> I have experienced following behavior when removing files.
> 
>  
> 
> I open a repository. I would like to delete all files, so I use
> 
> fossil rm ./*
> 
> In the output of the commandline the filenames (also with 
> subdirectories) with DELETED in front appeared.

Do you also get a message about some file not being in the repository? 
It looks like 'rm' getting an error like this abandons the operation, so 
none of the deletes are recorded.  "fossil rm ." appears to do the same 
thing, but it tells you which files it's skipping, although it doesn't 
say that it's not doing anything because of it.

-J

> 
> When I try to commit the deleted files with
> 
> fossil commit –m “remove all files”
> 
> I get a response : nothing to commit
> 
>  
> 
> I can only remove files out of the repository per typing every single 
> file. Is this an expected behavior?
> 
>  
> 
> Best regards
> 
>   Bernhard
> 
>  
> 
> 
> 
> 
> ___
> 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

Re: [fossil-users] fossil rm ./*

[Richard Hipp]

On Thu, Jun 24, 2010 at 10:37 AM, Kohn Bernhard wrote:

>  Hello all,
>
>
>
> I have experienced following behavior when removing files.
>
>
>
> I open a repository. I would like to delete all files, so I use
>
> fossil rm ./*
>
> In the output of the commandline the filenames (also with subdirectories)
> with DELETED in front appeared.
>
> When I try to commit the deleted files with
>
> fossil commit –m “remove all files”
>
> I get a response : nothing to commit
>
>
>
> I can only remove files out of the repository per typing every single file.
> Is this an expected behavior?
>
Try this:

fossil rm `fossil ls`

Removing all the files from a repository seems to me to be a obscure corner
case (in 35 years of programming, it is not something that I've ever wanted
to do before - why not just start a new project?)  So it seems to me that
leveraging the unix shell to get the job done, as shown above is not an
especially onerous task.  Adding support for wildcards on "fossil rm" is not
a priority.


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


-- 
-
D. Richard Hipp
d...@sqlite.org
___
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 rm ./*

[Kohn Bernhard]

Hello all,

I have experienced following behavior when removing files.

I open a repository. I would like to delete all files, so I use
fossil rm ./*
In the output of the commandline the filenames (also with subdirectories) with 
DELETED in front appeared.
When I try to commit the deleted files with
fossil commit -m "remove all files"
I get a response : nothing to commit

I can only remove files out of the repository per typing every single file. Is 
this an expected behavior?

Best regards
  Bernhard

___
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] usage of fossil settings ignore-glob in combination with add and commit

[Richard Hipp]

On Thu, Jun 24, 2010 at 9:28 AM, Kohn Bernhard wrote:

>  Hello all,
>
>
>
> thank you very much, with the batch-script I have the functionality I
> needed!
>
>
>
> But notheless, should add not behave like extras and changes in respect to
> the ignore-glob setting?
>

Yes, probably so.  I'll make a note to fix this.

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


-- 
-
D. Richard Hipp
d...@sqlite.org
___
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] usage of fossil settings ignore-glob in combination with add and commit

[Kohn Bernhard]

Hello all,

thank you very much, with the batch-script I have the functionality I needed!

But notheless, should add not behave like extras and changes in respect to the 
ignore-glob setting?

best regards
  Bernhard




___
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 rebase

[Michael Richter]

I'm not a git user, so I have no idea.

On 24 June 2010 18:56,  wrote:

> I'm not sure. Is there really no difference?
>
> - Altu
>
>
>
> -Original Message-
> From: Michael Richter 
> To: fossil-users@lists.fossil-scm.org
> Sent: Thu, Jun 24, 2010 4:23 pm
> Subject: Re: [fossil-users] fossil rebase
>
>
> What does this do that fossil merge trunk from my branch in
> ttmrichter doesn't do?
>
>
> On 24 June 2010 16:31,   wrote:
> Well, you have custom changes (A, B, C) in a branch and you want to
> keep up with latest changes happening in trunk - at frequent intervals.
>
> What rebase does is it applies your changes A, B & C to new head (G)
> with a knowledge of everything that has happened between E & G. If any
> of A, B or C was pulled in to the trunk, that change will be removed
> automatically.
>
>
> - Altu
>
>
> -Original Message-
> From: Eric 
>
> To: fossil-users@lists.fossil-scm.org
> Sent: Thu, Jun 24, 2010 12:00 pm
> Subject: Re: [fossil-users] fossil rebase
>
>
>
> > Git rebase help has a very good graphic to explain what it does:>>
> Assume the following history exists and the current branch is
> "topic":>>   A---B---C topic>  /> D---E---F---G
> master>> From this point, the result of either of the following
> commands:>> git rebase master> git rebase master topic> would be:>>
>A'--B'--C' topic>  /> D---E---F---G
> master>> Here, git forgets versions A, B & C if they are not published
> (tagged).> I agree we don't want fossil to forget anything.>> However,
> if fossil can do following, that would be very helpful:>>
> A---B---C topic>/>   /   A'--B'--C' (new name)>
>   /   /> D---E---F---G trunk>> - Altu>But why would
> anyone want to do
> that?E.___fossil-users
> mailing
>
> listfossil-us...@lists.fossil-scm.orghttp://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
>
>
>
>
>
> --
> "Perhaps people don't believe this, but throughout all of the
> discussions of entering China our focus has really been what's best for
> the Chinese people. It's not been about our revenue or profit or
> whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil"
> mantra.
>
>
> ___fossil-users mailing
> listfossil-us...@lists.fossil-scm.orghttp://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
>



-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
___
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 rebase

[altufaltu]

I'm not sure. Is there really no difference?

- Altu



-Original Message-
From: Michael Richter 
To: fossil-users@lists.fossil-scm.org
Sent: Thu, Jun 24, 2010 4:23 pm
Subject: Re: [fossil-users] fossil rebase


What does this do that fossil merge trunk from my branch in 
ttmrichter doesn't do?


On 24 June 2010 16:31,   wrote:
Well, you have custom changes (A, B, C) in a branch and you want to
keep up with latest changes happening in trunk - at frequent intervals.

What rebase does is it applies your changes A, B & C to new head (G)
with a knowledge of everything that has happened between E & G. If any
of A, B or C was pulled in to the trunk, that change will be removed
automatically.


- Altu


-Original Message-
From: Eric 

To: fossil-users@lists.fossil-scm.org
Sent: Thu, Jun 24, 2010 12:00 pm
Subject: Re: [fossil-users] fossil rebase



> Git rebase help has a very good graphic to explain what it does:>>
Assume the following history exists and the current branch is
"topic":>>           A---B---C topic>          />     D---E---F---G
master>> From this point, the result of either of the following
commands:>> git rebase master> git rebase master topic> would be:>>
               A'--B'--C' topic>                  />     D---E---F---G
master>> Here, git forgets versions A, B & C if they are not published
(tagged).> I agree we don't want fossil to forget anything.>> However,
if fossil can do following, that would be very helpful:>>
A---B---C topic>            />           /       A'--B'--C' (new name)>
          /       />     D---E---F---G trunk>> - Altu>But why would
anyone want to do
that?E.___fossil-users
mailing

listfossil-us...@lists.fossil-scm.orghttp://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





--
"Perhaps people don't believe this, but throughout all of the 
discussions of entering China our focus has really been what's best for 
the Chinese people. It's not been about our revenue or profit or 
whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" 
mantra.


___fossil-users mailing 
listfossil-us...@lists.fossil-scm.orghttp://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

Re: [fossil-users] usage of fossil settings ignore-glob in combination with add and commit

[Kohn Bernhard]

Hello all,

I had this situation on a windows system (windows server 2003)

Best regards
  Bernhard

___
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] usage of fossil settings ignore-glob in combination with add and commit

[Kevin Greiner]

On Thu, Jun 24, 2010 at 7:24 AM, Kohn Bernhard wrote:

>  But when I run fossil add . to add all the files, every file and also the
> ones which applies to the ignore-glob setting are added. If I commit then,
> also the not wanted files are added to the repository. Exist there a way,
> that only files will be added, which don’t apply to the ignore-glob setting?
>

I had the same problem a few days ago. Can someone explain why "add" and
"extras" work differently with respect to the ignore-glob setting?

You don't say what operating system you are using but I assume a *nix based
on your path separator. So something along these lines should work:

fossil extras | xargs -I{} --verbose fossil add "{}"

I use Windows at work and had to resort to this:

fossil extras | xargs2 /addquotes fossil add

where "xargs2" is the batch file:
http://blogs.msdn.com/b/matthew_van_eerde/archive/2008/11/25/xargs-start.aspx
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] usage of fossil settings ignore-glob in combination with add and commit

[Kohn Bernhard]

Hello all,

I started recently to use fossil for a small software project, and I must say, 
I am very pleased how easy it is to use!

But I have a problem using the ignore-glob settings together with add and 
commit.
If I understand it the right way, the ignore-glob settings prevents one from 
commiting files of special output-type (eg. Debug/* of object code files etc.).
When I set the option to */Debug/* and use the command extras and changes I 
don't see any stuff which applies to the ignore-glob setting.
But when I run fossil add . to add all the files, every file and also the ones 
which applies to the ignore-glob setting are added. If I commit then, also the 
not wanted files are added to the repository. Exist there a way, that only 
files will be added, which don't apply to the ignore-glob setting?

Best regards
  Bernhard
___
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 rebase

[Michael Richter]

What does this do that *fossil merge trunk* from my branch in
*ttmrichter* doesn't
do?

On 24 June 2010 16:31,  wrote:

> Well, you have custom changes (A, B, C) in a branch and you want to
> keep up with latest changes happening in trunk - at frequent intervals.
>
> What rebase does is it applies your changes A, B & C to new head (G)
> with a knowledge of everything that has happened between E & G. If any
> of A, B or C was pulled in to the trunk, that change will be removed
> automatically.
>
> - Altu
>
>
> -Original Message-
> From: Eric 
> To: fossil-users@lists.fossil-scm.org
> Sent: Thu, Jun 24, 2010 12:00 pm
> Subject: Re: [fossil-users] fossil rebase
>
>
> > Git rebase help has a very good graphic to explain what it does:>>
> Assume the following history exists and the current branch is
> "topic":>>   A---B---C topic>  /> D---E---F---G
> master>> From this point, the result of either of the following
> commands:>> git rebase master> git rebase master topic> would be:>>
>   A'--B'--C' topic>  /> D---E---F---G
> master>> Here, git forgets versions A, B & C if they are not published
> (tagged).> I agree we don't want fossil to forget anything.>> However,
> if fossil can do following, that would be very helpful:>>
> A---B---C topic>/>   /   A'--B'--C' (new name)>
>  /   /> D---E---F---G trunk>> - Altu>But why would
> anyone want to do
> that?E.___fossil-users
> mailing
> listfossil-us...@lists.fossil-scm.orghttp://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
>



-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
___
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 rebase

[altufaltu]

Well, you have custom changes (A, B, C) in a branch and you want to 
keep up with latest changes happening in trunk - at frequent intervals.

What rebase does is it applies your changes A, B & C to new head (G) 
with a knowledge of everything that has happened between E & G. If any 
of A, B or C was pulled in to the trunk, that change will be removed 
automatically.

- Altu


-Original Message-
From: Eric 
To: fossil-users@lists.fossil-scm.org
Sent: Thu, Jun 24, 2010 12:00 pm
Subject: Re: [fossil-users] fossil rebase


> Git rebase help has a very good graphic to explain what it does:>> 
Assume the following history exists and the current branch is 
"topic":>>   A---B---C topic>  /> D---E---F---G 
master>> From this point, the result of either of the following 
commands:>> git rebase master> git rebase master topic> would be:>> 
   A'--B'--C' topic>  /> D---E---F---G 
master>> Here, git forgets versions A, B & C if they are not published 
(tagged).> I agree we don't want fossil to forget anything.>> However, 
if fossil can do following, that would be very helpful:>> 
A---B---C topic>/>   /   A'--B'--C' (new name)> 
  /   /> D---E---F---G trunk>> - Altu>But why would 
anyone want to do 
that?E.___fossil-users 
mailing 
listfossil-us...@lists.fossil-scm.orghttp://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