ontent with you private branch, you
have to switch to the trunk (or whatever your target is, via
fossil update trunk
and then merge your private branch into the trunk via
fossil merge
. Check the changes, resolve any conflict and if you content with your
re
hat's the correct way to bring a
> private thread back to the trunk?
this all is a bit clumsy. You should simply work with your private
branch until you are content with its state. Then you simply merge your
private branch back onto your "trunk". Sync it and done ...
Ciao,
chi
spelled "binPaht"?
Shouldn't this read "binPath" perhaps?
(...)
Ciao,
chi :-)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ould do is to warn on every commit I do until those
auto-stashes are dropped again (perhaps with asking for permission to
proceed with current checkin in face of auto-stashes).
Ciao,
chi :-)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ate should never delete uncommitted changed files.
> Zed's post implies this happened.
The 'stash first' should protect us here too :-)
(...)
Just my two cent ...
Ciao,
chi :-)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
prefix and therefore
*cannot* being used at command line to select a commit instead of using
its SHA1 sum.
But as it has assigned a value to it ("branch=branchname") Fossil know
on which branch the current commit currently resides. If there were no
such property, Fossil wouldn'
y by upcase/lowcase spelling and are checking out on a
filesystem that regard e.g. 'FOO.c' and 'foo.c' as the same filename
(e.g. NTFS or HFS+).
Does one of this explanation is matching your environment?
Best regards,
chi.
(...)
___
fossi
e's privacy on a raw-tag instead of an entry in a local SQL table
within the repository?
What is your opinion?
Regards,
chi.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ussions concerning
this thread, and if nothing speaks against this, you could try to open
an improvement ticket with your proposal. Except -- of course -- if DRH
already rejected it here on the mailing list at that time ...
Ciao,
chi.
___
fossil-users ma
e or another setting locally.
Ciao,
chi.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ly as they are
immutable after creation. In the "normal" case only new files are added
during modification of the repository state, AFAIR.
So I guess it is not really the same issue as with Fossil.
Ciao,
chi.
(...)
___
fossil-users mailing list
f
t I believe, that Fossil do held some further metadata also contained
in the artifacts in extra tables for performance reasons (kind of
cache). These tables can easily be repopulated at will with
fossil rebuild
if necessary (i.e. the database format has changed). :-)
(...)
Ciao,
chi.
___
s own "manifest" and then complain about checksum mismatch
...
Ciao,
chi.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> 0. Number one
> 0. Number two
> 0. Number three
>
> That's not really a numbered list, now, is it?
Ahhh ... in my Fossil wiki it gives me:
1. Number one
2. Number two
3. Number three
Try for yourself in the Fossil wiki's sandbox ...
#x27;open' command. But you need probably to know
the branch and perhaps the revision you were at, as my command given
above would try to open against the 'trunk' and there the last version.
Better to read the help of the 'open' command first.
Ciao,
chi :-)
(..
ing worked out :-)
Thank you,
chi.
(...)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
s despite the permission.
If this is the case, you would have either to change and publish the
anonymous password for users that would like to clone (the login
password for anonymous will still be generated automatically to be
different for every login), or you would have to allow user nobody
Will Duquette wrote:
> Chi,
>
Hello Will,
> Thanks for the word about the bug fix. I'll see about updating to the
> latest Fossil binary; I'd been putting it off until there was some
> compelling reason. :-)
>
I am lucky, that my answer was helpful
d and therefore does not contain the fix.
So if you upgrade your binary (and probably fossil rebuild the
repository) the problem should vanish ...
BTW: Does you also host your excellent Notebook and Snit with Fossil?
(...)
Best regards,
chi
__
19 matches
Mail list logo
