Hello,
I have not tried, but what should I expect if I try to use a new branch naming
it as a branch already closed?
Is it something I will not be able to do, or something I should try to avoid?
And a bit unrelated, the branch comes determined from the 'branch' tag, and not
from the
On Mon, Oct 4, 2010 at 4:25 AM, Christian Busch busch.christ...@gmx.dewrote:
Hi all,
I'm evaluating fossil as a scm for the developement of testing software
for embedded system testing. There will be a huge amount of test
scripts and after a test run there might be a lot of found problems
2010/10/4 Lluís Batlle i Rossell virik...@gmail.com
Hello,
I have not tried, but what should I expect if I try to use a new branch
naming
it as a branch already closed?
Is it something I will not be able to do, or something I should try to
avoid?
That works fine. We do it all the time.
Since tickets are configurable on a site-by-site basis, I is difficult to
imagine
what a command-line interface to the ticketing system might look like. Do
you have any suggestions?
Yes, I do.
I've developed a GUI for fossil (inside RamDebugger), that permits to select
an open ticket and add
Ramon Ribó ram...@... writes:
:
So, It would be enough for this application to have the possibility of
changing the status of the ticket.
It would be also nice to have a more ordered list of tickets with its id,
comment and status so as to avoid parsing fossil timeline -t t
RR2010/10/4
Hello,
I was using a poor script I wrote to move from svn to fossil, and I was getting
the deleted files through the MISSING lines of 'fossil changes'. But I hit a
long filename that fossil shortened using elipsis before the extension. The
output I got was:
MISSINGdoc/Induction/Camera design
Christian Busch busch.christ...@... writes:
That's looking perfect for me!
I was about to require the add-comand, because this is the first thing
I would need. Also the ability of checking and adding own defined
field-value pairs would be very helpful.
Anybody has further ideas to
Hello,
I'm trying to migrate a Trac workflow to Fossil. Here's what it looks like:
For each feature:
1. create ticket
2. create branch
3. implement
4. submit branch for review
5. review: if not good, back to 3
6. merge branch to trunk
(trunk gets handed off to continuous integration/deployment
On Mon, Oct 04, 2010 at 10:55:02PM +0200, Laurens Van Houtven wrote:
Hello,
I'm trying to migrate a Trac workflow to Fossil. Here's what it looks like:
For each feature:
1. create ticket
2. create branch
3. implement
4. submit branch for review
5. review: if not good, back to 3
6.
On Mon, Oct 4, 2010 at 6:02 PM, Laurens Van Houtven l...@laurensvh.bewrote:
2010/10/4 Lluís Batlle i Rossell virik...@gmail.com:
On Mon, Oct 04, 2010 at 10:55:02PM +0200, Laurens Van Houtven wrote:
You can review against the trunk version it was updated from. As any
DVCS,
fossil does not
2010/10/4 Lluís Batlle i Rossell virik...@gmail.com
On Mon, Oct 04, 2010 at 10:55:02PM +0200, Laurens Van Houtven wrote:
I wonder how difficult it will be in fossil to find the version of the
parent
branch last merged into a child branch.
Fossil does this automatically for you when you
Hi everyone,
I started using Fossil few days ago, after listening to Fossil BSD talk[1],
and so far, I'm happy with its feature set. Thanks :)
Recently I wanted to revert a commit to previous one (git equivalent: git
reset HEAD^), and I used following commands:
% git checkout
On Mon, Oct 4, 2010 at 9:50 PM, Ashish SHUKLA wahjava...@gmail.com wrote:
Hi everyone,
I started using Fossil few days ago, after listening to Fossil BSD talk[1],
and so far, I'm happy with its feature set. Thanks :)
Recently I wanted to revert a commit to previous one (git equivalent: git
13 matches
Mail list logo
