Hi List,
In one of my projects I am mostly working on one specific branch XYZ.
But, being a novice fossil user, I mistakenly messed up the trunk.
Now, how can i push only my branch XYZ without pushing whatever was
entered into the trunk?
Is shunning my only option?
Are there plans to implement
For some time now, the SQLite and Fossil websites have been running on the
retro-sbsdiff branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors
and decoration and provides plain-text output - essentially the same output
On Fri, Feb 03, 2012 at 10:25:41AM -0500, Richard Hipp wrote:
For some time now, the SQLite and Fossil websites have been running on the
retro-sbsdiff branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors
and
On 02/03/12 16:25, Richard Hipp wrote:
[---]
Are there strong preferences one way or another?
There are two aspects I prefer with the original:
- I think color coding makes it easier to get a quick overview of
what's happened in a diff. (I see a lot of red is roughly
optimizations, I see a
My preference would be to keep the color SBS diffs, at least as a skin
option or something, since I find it easier to notice changes and match
them up. Maybe somewhere in the documentation on the header / skin, there
could be css for a default coloring of the sbs diffs that one could copy
into the
On Fri, Feb 3, 2012 at 8:25 AM, Richard Hipp d...@sqlite.org wrote:
For some time now, the SQLite and Fossil websites have been running on the
retro-sbsdiff branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors
and
If I do:
fossil rm some/file.txt
rm some/file.txt
...do stuff...
fossil update
then some/file.txt is resurrected which is really really annoying when you
just got your build to work and then because files that shouldn't be there
suddenly reappear and things break.
I can see where might be some
On 02/03/12 17:01, Tomek Kott wrote:
My preference would be to keep the color SBS diffs, at least as a skin
option or something, since I find it easier to notice changes and match
them up. Maybe somewhere in the documentation on the header / skin, there
could be css for a default coloring of
On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson
jan.m.daniels...@gmail.comwrote:
- I haven't looked at the code lately, but does the web sbsdiff
support the width argument in some manner? For quite a few diffs I've
been looking at lately, static 80 characters wide panes leaves a lot of
On Wed, Feb 1, 2012 at 8:03 AM, Leo Razoumov slonik...@gmail.com wrote:
On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote:
The clock according to the D card of the artifact.
In other words, you can keep changing the value of a tag and the latest
version always wins.
If two
On Fri, Feb 03, 2012 at 11:19:38AM -0500, Richard Hipp wrote:
On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson
jan.m.daniels...@gmail.comwrote:
- I haven't looked at the code lately, but does the web sbsdiff
support the width argument in some manner? For quite a few diffs I've
been
On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
If I do:
fossil rm some/file.txt
rm some/file.txt
fossil commit
--
Dmitry Chestnykh
http://www.codingrobots.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
On 2/3/2012 7:25 AM, Richard Hipp wrote:
For some time now, the SQLite and Fossil websites have been running on the
retro-sbsdiff branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors and
decoration and provides
On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.comwrote:
On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
If I do:
fossil rm some/file.txt
rm some/file.txt
fossil commit
People often prefer to commit when their work has reached some level of
completion or
On Fri, Feb 3, 2012 at 11:56 AM, Andreas Kupries
andre...@activestate.comwrote:
On 2/3/2012 7:25 AM, Richard Hipp wrote:
For some time now, the SQLite and Fossil websites have been running on the
retro-sbsdiff branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for
On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland estifo...@gmail.com wrote:
On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.com
wrote:
On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
If I do:
fossil rm some/file.txt
rm some/file.txt
fossil commit
People often
I think part of the original post was whether the documentation was
correct. i.e., it says uncommitted changes are retained. I would argue that
fossil rm is an uncommitted change, which should be retained. Either the
documentation is wrong or there is a bug w.r.t. fossil rm.
As a work around, you
On Fri, Feb 3, 2012 at 11:18 AM, Matt Welland estifo...@gmail.com wrote:
If I do:
fossil rm some/file.txt
rm some/file.txt
...do stuff...
fossil update
then some/file.txt is resurrected which is really really annoying when you
just got your build to work and then because files that
On Feb 1, 2012, at 15:18 , Chris Peachment wrote:
I can't speak for MS-Windows or MacOS but Ubuntu Linux uses
NTP by default.
So does OS X.
Kind regards,
Remigiusz Modrzejewski
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
On Fri, Feb 3, 2012 at 6:33 PM, Weber, Martin S martin.we...@nist.govwrote:
On 2012-02-03 12:31 , Remigiusz Modrzejewski l...@maxnet.org.pl wrote:
I'm for color-coded. All of the reasons have already been listed in the
thread.
Same here.
If not color coded, perhaps adding
I'd be happy with Stephan's suggestion, since it would satisfy both parties
with a little work on the colorizing side. I think the only additional
point is to have the div or whatever surrounds the code to have a good
descriptive class we can latch on to with JS.
Tomek
On Fri, Feb 3, 2012 at
On 02/03/12 18:40, Stephan Beal wrote:
I'm for color-coded. All of the reasons have already been listed in the
thread.
Same here.
If not color coded, perhaps adding add/change/remove markers to the _start_
of each line, since that would make JS-scripting the colorification
relatively
Hi List,
I am using fossil version-1.21 on Linux Ubuntu-10.04 and am getting
weird corruption of the cloned repository.
If you would like to reproduce the problem you can download the repository from:
http://www.panix.com/~leor/fos/fos.fossil.bz2
Username: fossil
Password: fossil-scm
Here is
On Fri, Feb 3, 2012 at 8:17 PM, Jan Danielsson
jan.m.daniels...@gmail.comwrote:
I wouldn't like that change very much. I think the way and are
used now is very intuitive, and it creates a nice separator column with
i agree but having them in the middle makes it literally impossible to
On Fri, Feb 03, 2012 at 08:33:41PM +0100, Stephan Beal wrote:
How much work would it be to put together a proof-of-concept sbsdiff
colorizer?
The new diffs can't reliably be colored using JS because of potential
syntactic ambiguities. It would work often but not always.
The sbs diffs
On Fri, Feb 3, 2012 at 8:23 PM, Leo Razoumov slonik...@gmail.com wrote:
Now in the cloned repo fos2.fossil the old *public* branch
exp-search is not accesible anymore.
When i try this exp-search is still visible under the branches list, but i
see no commits for it.
For instance
On Fri, Feb 3, 2012 at 14:41, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Feb 3, 2012 at 8:23 PM, Leo Razoumov slonik...@gmail.com wrote:
Now in the cloned repo fos2.fossil the old *public* branch
exp-search is not accesible anymore.
When i try this exp-search is still visible
I installed the fossil package from the Ubuntu repository, but it was
quite old, so I decided to update from source. However, I encountered a
couple issues when trying to generate the .deb, mainly, the official
package is named fossil and the makedeb.sh script creates fossil-scm.
This creates a
Hi Richard,
I am afraid I found a bug in fossil scm version-1.21.
Clone operation drops relevant commits and artifacts in a public
branch causing loss of data.
Please, find below a minimal case that demonstrates the bug on Linux
(Ubuntu-10.04).
For your convenience I wrapped the commands into a
On Fri, Feb 3, 2012 at 5:36 PM, Leo Razoumov slonik...@gmail.com wrote:
Hi Richard,
I am afraid I found a bug in fossil scm version-1.21.
Clone operation drops relevant commits and artifacts in a public
branch causing loss of data.
Please, find below a minimal case that demonstrates the bug
On Fri, Feb 3, 2012 at 5:36 PM, Leo Razoumov slonik...@gmail.com wrote:
Hi Richard,
I am afraid I found a bug in fossil scm version-1.21.
Clone operation drops relevant commits and artifacts in a public
branch causing loss of data.
Please, find below a minimal case that demonstrates the bug
hi there,
reading through the documentation i thought some sentences
would be easier to read with some minor changes, and i also
removed end of line whitespace.
the other item from the subject concerns the future change
of '_FOSSIL_' to '.fos'. i am totally new on the list, so
i am not familiar
32 matches
Mail list logo
