Hello,
in the past I have sometimes encoded the date-of-creation of a dir
into the dir-name. I am guessing this is a bit silly, because this
information is exactly what is provided by an SCM-tool such as
fossil.
Can I, given a subdir in the working tree, quickly get an overview of
On 18 July 2014 12:14, Michai Ramakers m.ramak...@gmail.com wrote:
in the past I have sometimes encoded the date-of-creation of a dir
into the dir-name.
...assuming there are actual files in that dir.
___
fossil-users mailing list
On 18 July 2014 12:14, Michai Ramakers m.ramak...@gmail.com wrote:
Can I, given a subdir in the working tree, quickly get an overview of
creation-dates of files/dirs in that dir (recursive or toplevel-only,
that's mostly irrelevant to me), using the CLI?
ok, 'fossil ls --age', should have
On Fri, Jul 18, 2014 at 12:14 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
in the past I have sometimes encoded the date-of-creation of a dir
into the dir-name. I am guessing this is a bit silly, because this
information is exactly what is provided by an SCM-tool such as
fossil.
i don't
On 18 July 2014 12:20, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jul 18, 2014 at 12:14 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
in the past I have sometimes encoded the date-of-creation of a dir
into the dir-name. I am guessing this is a bit silly, because this
information is
On Thu, Jul 17, 2014 at 8:38 PM, Stephan Beal sgb...@googlemail.com wrote:
Unless i get called off of vacation back to work next week, i should
have the remaining bits ported from the older binding by this time next
week.
The core API bits have all been ported to s2. Sample scripts/unit
I'm using the latest tip version of Fossil, and am getting this
complaint on checkins:
Autosync: http://me@server:3691/server
Round-trips: 1 Artifacts sent: 0 received: 0
Pull finished with 343 bytes sent, 716 bytes received
vim ../../ci-comment-B545A069E3EC.txt
New_Version:
On Fri, Jul 18, 2014 at 11:25 AM, Warren Young war...@etr-usa.com wrote:
I'm using the latest tip version of Fossil, and am getting this complaint
on checkins:
Autosync: http://me@server:3691/server
Round-trips: 1 Artifacts sent: 0 received: 0
Pull finished with 343 bytes sent, 716
On Fri, Jul 18, 2014 at 3:27 PM, Stephan Beal sgb...@googlemail.com wrote:
The core API bits have all been ported to s2. Sample scripts/unit tests:
http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/dir/s2/unit2
There's some utility-level code left to port (filesystem utils and such)
Thus said Warren Young on Fri, 18 Jul 2014 09:25:12 -0600:
The DB is on a local ext3 filesystem, so there shouldn't be anything
going on related to non-POSIX semantics.
Is the repository that the server is serving up an actual file, or is it
a link of some kind?
Andy
--
TAI64 timestamp:
It seems it is not possible to commit to a new branch from a closed branch.
this is version 1.28.
I think this should be allowed. Closing a branch only implies to me that no
more commits are to be made to that branch.
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to
On 7/18/2014 09:28, Richard Hipp wrote:
Presumably you get the same error when you do fossil sync or fossil
push, right?
Actually, I think I just figured it out:
$ fossil server /museum # where I keep my *.fossils
$ fossil open /museum/repo.fossil
$ fossil sync
On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com wrote:
It seems it is not possible to commit to a new branch from a closed
branch. this is version 1.28.
I think this should be allowed. Closing a branch only implies to me that
no more commits are to be made to that branch.
Stephan Beal wrote:
On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com wrote:
It seems it is not possible to commit to a new branch from a closed
branch. this is version 1.28.
I think this should be allowed. Closing a branch only implies to me that
no more commits are
On Fri, Jul 18, 2014 at 10:23 AM, Eric Rubin-Smith eas@gmail.com
wrote:
Stephan Beal wrote:
On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com
wrote:
It seems it is not possible to commit to a new branch from a closed
branch. this is version 1.28.
I think
Matt Welland wrote:
From http://www.fossil-scm.org/index.html/doc/tip/www/branching.wiki:
==
Closed Leaf
A closed leaf is any leaf with the closed tag. These leaves are
intended to never be extended with descendants and hence are omitted
from lists of leaves in the
On Fri, Jul 18, 2014 at 1:16 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com wrote:
It seems it is not possible to commit to a new branch from a closed
branch. this is version 1.28.
I think this should be allowed. Closing a
fossil help timeline talks about a BASELINE. I've discovered by
playing that it can be an artifact ID, but I assume there has to be more
to it than that, else why use a different term?
Neither the Schimpf book nor fossil help really explain the term. It
doesn't appear on the documentation
On Fri, Jul 18, 2014 at 8:23 PM, Ron W ronw.m...@gmail.com wrote:
To get the feature Matt suggested, I suggested adding a new Fossil defined
tag and adding the the following after the code cited above (inserting the
needed conditional in the new if):
/*
** If not creating a new branch, do
The scenario I'd like to see supported is roughly as follows:
Work on a release is done. The release manager closes the branch so no one
can accidentally merge or commit to it.
A bug fix is needed. The developer branches off the closed node and fixes
the bug and runs QA.
The release manager can
On Fri, Jul 18, 2014 at 8:30 PM, Warren Young war...@etr-usa.com wrote:
fossil help timeline talks about a BASELINE. I've discovered by playing
that it can be an artifact ID, but I assume there has to be more to it than
that, else why use a different term?
Neither the Schimpf book nor
Baseline is an older name for check-in. It drives from DO-178B
language.
We should updates the timeline help to say check-in instead, as that will
be clearer to most readers, I think.
On Fri, Jul 18, 2014 at 2:30 PM, Warren Young war...@etr-usa.com wrote:
fossil help timeline talks about a
On Fri, Jul 18, 2014 at 8:39 PM, Warren Young war...@etr-usa.com wrote:
When I am assembling a new software release, I assemble a ChangeLog from
the checkin comments since the last release. Prior to moving to Fossil, I
used svn log -r12345:HEAD for this. That lists the checkin comments from
On Fri, Jul 18, 2014 at 2:39 PM, Warren Young war...@etr-usa.com wrote:
When I am assembling a new software release, I assemble a ChangeLog from
the checkin comments since the last release.
On SQLite and on Fossil I do this:
http://www.sqlite.org/src/timeline?a=releaset=trunkn=1000
On Fri, Jul 18, 2014 at 8:43 PM, Stephan Beal sgb...@googlemail.com wrote:
Here's how we do it for fossil releases:
http://www.fossil-scm.org/fossil/vdiff?from=releaseto=trunkdetail=1
Correction: that's the diff for that range. Richard's solution gives you
the commit comments.
--
-
On Fri, Jul 18, 2014 at 2:17 PM, Eric Rubin-Smith eas@gmail.com wrote:
Matt Welland wrote:
In that case I'd suggest a new mechanism - locked with the behavior I
described.
I dunno. In my mind one of fossil's big advantages is that stays out
of your way because it has a limited number
On Fri, Jul 18, 2014 at 2:40 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jul 18, 2014 at 8:30 PM, Warren Young war...@etr-usa.com wrote:
fossil help timeline talks about a BASELINE. I've discovered by
playing that it can be an artifact ID, but I assume there has to be more to
it
On Fri, Jul 18, 2014 at 2:33 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jul 18, 2014 at 8:23 PM, Ron W ronw.m...@gmail.com wrote:
To get the feature Matt suggested, I suggested adding a new Fossil
defined tag and adding the the following after the code cited above
(inserting the
On Fri, Jul 18, 2014 at 8:40 PM, Stephan Beal sgb...@googlemail.com wrote:
i've got a simple browser which might make this clearer:
http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest
This one's a good example:
On Fri, Jul 18, 2014 at 2:23 PM, Ron W ronw.m...@gmail.com wrote:
/*
** If not creating a new branch, do not allow a commit against a closed
branch
*/
if( /* not creating new branch */ ){
I think if you wanted to be pedantic, you should also check to make sure
that the new branch name
On 7/18/2014 12:39, Richard Hipp wrote:
We should updates the timeline help to say check-in instead, as that
will be clearer to most readers, I think.
Sounds good. Baseline appears in the help for
/ci_edit
/doc
/info
/zip
3-way-merge
ci (as --baseline)
On Fri, Jul 18, 2014 at 2:55 PM, Warren Young war...@etr-usa.com wrote:
On 7/18/2014 12:39, Richard Hipp wrote:
We should updates the timeline help to say check-in instead, as that
will be clearer to most readers, I think.
Sounds good. Baseline appears in the help for
/ci_edit
Matt Welland wrote:
The scenario I'd like to see supported is roughly as follows:
Work on a release is done. The release manager closes the branch so no
one can accidentally merge or commit to it.
A bug fix is needed. The developer branches off the closed node and
fixes the bug
On Fri, Jul 18, 2014 at 2:39 PM, Warren Young war...@etr-usa.com wrote:
When I am assembling a new software release, I assemble a ChangeLog from
the checkin comments since the last release. Prior to moving to Fossil, I
used svn log -r12345:HEAD for this. That lists the checkin comments from
On Fri, Jul 18, 2014 at 9:03 PM, Eric Rubin-Smith eas@gmail.com wrote:
in Fossil. For example, perhaps you wish that you could say user A can
create check-ins but cannot open or close branches.
That would break down if someone tried checking in with the --close,
--branch, or --integrate
On Fri, Jul 18, 2014 at 2:55 PM, Warren Young war...@etr-usa.com wrote:
Baseline appears in the help for
ci (as --baseline)
If I understand the description in the help, --baseline forces the created
manifest to be a baseline manifest..
This seems reasonable. Perhaps the description can
On 7/18/2014 13:05, Ron W wrote:
fossil timeline after | perl -n -e print if /tags: .*branchname/;
That only works if your commit messages are so short they don't cause a
line wrap. I use an 80 column terminal window (old timer, me) so it
doesn't take much to cause a wrap. I tried
Personally I see limited usefulness in closing a leaf. It is branches that
need to be closed (albeit by closing a leaf).
I'll let the developers that are requesting this know that it ain't gonna
happen. As was suggested they can open/re-close the node as needed.
On Fri, Jul 18, 2014 at 12:09
On Fri, Jul 18, 2014 at 12:26 PM, Warren Young war...@etr-usa.com wrote:
Actually, I think I just figured it out:
$ fossil server /museum # where I keep my *.fossils
$ fossil open /museum/repo.fossil
$ fossil sync http://me@server/repo
...hack, hack, hack...
On 7/18/2014 12:44, Richard Hipp wrote:
http://www.sqlite.org/src/timeline?a=releaset=trunkn=1000
I think clicking the branch from fossil ui then appending a=AFTERSPEC
will work for me:
http://server:port/repo/timeline?r=BRANCHNAMEa=AFTERSPEC
Today I also learned you can say fossil
On Fri, Jul 18, 2014 at 3:34 PM, Warren Young war...@etr-usa.com wrote:
On 7/18/2014 13:05, Ron W wrote:
fossil timeline after | perl -n -e print if /tags: .*branchname/;
That only works if your commit messages are so short they don't cause a
line wrap. I use an 80 column terminal
On Fri, Jul 18, 2014 at 3:23 PM, Ron W ronw.m...@gmail.com wrote:
On Fri, Jul 18, 2014 at 2:55 PM, Warren Young war...@etr-usa.com wrote:
Baseline appears in the help for
ci (as --baseline)
If I understand the description in the help, --baseline forces the created
manifest to be a
Thus said Matt Welland on Fri, 18 Jul 2014 12:41:55 -0700:
Personally I see limited usefulness in closing a leaf. It is branches
that need to be closed (albeit by closing a leaf).
I think this brings up a fine distinction. The behavior of disallowing a
descendent checkin applies to a leaf,
On Fri, Jul 18, 2014 at 3:58 PM, Warren Young war...@etr-usa.com wrote:
It may be that SQLite has changed the way it does locking since you tried
this. Different OSes also affect the way SQLite does locking.
Most of us are running fossil server even though we no longer do
peer-to-peer sync.
Thus said Warren Young on Fri, 18 Jul 2014 13:58:38 -0600:
It doesn't completely fail. The checkins do occur; fossil just gripes
about it. (This might be the autosync retry feature at work.)
No, autosync only tries once by default in each direction
(pull/push)---the same as it
[Default] On Fri, 18 Jul 2014 13:34:26 -0600, Warren Young
war...@etr-usa.com wrote:
On 7/18/2014 13:05, Ron W wrote:
fossil timeline after | perl -n -e print if /tags: .*branchname/;
That only works if your commit messages are so short they don't cause a
line wrap. I use an 80 column
2014-07-18 20:53 GMT+02:00 Richard Hipp d...@sqlite.org:
On Fri, Jul 18, 2014 at 2:23 PM, Ron W ronw.m...@gmail.com wrote:
/*
** If not creating a new branch, do not allow a commit against a closed
branch
*/
if( /* not creating new branch */ ){
I think if you wanted to be pedantic,
Thus said Jan Nijtmans on Fri, 18 Jul 2014 23:58:09 +0200:
I interpret this message as:
http://fossil-scm.org/index.html/info/2b79c600d5
What if I do:
fossil up closedbranchname
fossil ci --branch closedbranchname
Andy
--
TAI64 timestamp: 400053c99bca
Hi Folks,
Just starting to play with Fossil. Installed it on my laptop, but the
install instructions on the wiki include this statement:
Released versions of fossil come with pre-compiled binaries and a
source archive http://www.fossil-scm.org/download.html for that
release. Which seems
On Fri, Jul 18, 2014 at 5:58 PM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2014-07-18 20:53 GMT+02:00 Richard Hipp d...@sqlite.org:
On Fri, Jul 18, 2014 at 2:23 PM, Ron W ronw.m...@gmail.com wrote:
/*
** If not creating a new branch, do not allow a commit against a
closed
branch
2014-07-19 1:02 GMT+02:00 Ron W ronw.m...@gmail.com:
Also, I had suggested separate tests for closed leaf and closed branch.
Fossil doesn't have the concept of a 'closed branch', it's only
the final leaf that can be closed. So I really don't know
how to implement that.
Regards,
Jan
Thanks!
Jan Nijtmans wrote:
2014-07-19 0:15 GMT+02:00 Miles Fidelman mfidel...@meetinghouse.net:
Hi Folks,
Just starting to play with Fossil. Installed it on my laptop, but the
install instructions on the wiki include this statement:
Released versions of fossil come with pre-compiled
On Fri, Jul 18, 2014 at 7:12 PM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2014-07-19 1:02 GMT+02:00 Ron W ronw.m...@gmail.com:
Also, I had suggested separate tests for closed leaf and closed branch.
Fossil doesn't have the concept of a 'closed branch', it's only
the final leaf that can
53 matches
Mail list logo
