Re: [fossil-users] [sqlite] Fossil code sprint. Was: DRH to be in Munich, Germany July 3rd, 2012

[Stephan Beal]

For those who missed the notice about Richard's visit the first time around:

https://plus.google.com/104981852298046595282/posts/JhpKW3zXScj


On Fri, May 25, 2012 at 9:45 PM, Richard Hipp  wrote:

> * User preferences stored in a cookie
>

Adding persistent user preferences on top of Fossil's JSON API would be (A)
really easy and (B) allow the preferences to be of near-arbitrary
complexity. e.g. it could be used to periodically store drafts of a wysiwyg
editing session (in addition to any user-specific repo-level config
options). Alternately/additionally, "session" support (storage valid as
long as the login token) would be really easy to add.


> The above list will likely grow.  So if you are planning to be in the
> Munich area on July 3 please stop by   Contact Stephen Beal for information
> on the venue.
>


Those who "register" with me will get details on when/where, once those are
finalized (the Where is decided, the exact When not so much).


> If this code sprint works out - if people show interest and useful work
> gets done - then I'll be happy to have follow-ups in other locations and on
> other continents.
>

But those visiting this first time around will always be able to say, "we
saw him before he was famous!" ;)


Happy Hacking!

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] "losing" history in private branch merge?

[Gour]

On Fri, 25 May 2012 15:28:02 -0400
Richard Hipp  wrote:

> So perhaps we should go back to the original design?

As far as private branches are concerned, I'd like to be able to
selectively rm single private branch when using 'scrub'.

Otoh, Mercurial has nice concept of Phases
(http://mercurial.selenic.com/wiki/Phases) controlling how changesets
are exchanged,

Moreover, 2.3 is preparing another interesting concept: 

http://hg-lab.logilab.org/doc/mutable-history/html/obs-concept.html


Sincerely,
Gour


-- 
A person is considered still further advanced when he regards honest 
well-wishers, affectionate benefactors, the neutral, mediators, the
envious, friends and enemies, the pious and the sinners all with an
equal mind.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
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] "losing" history in private branch merge?

[Andreas Kupries]

On 5/25/2012 12:28 PM, Richard Hipp wrote:

So, clearly, I just need to revisit the whole "private branch" concept

As originally implemented, private branches were just a marking in the
database.  But then somebody (aku?)


While I don't remember that, it would certainly be in my line of thinking on 
seeing such a design.


> pointed out that if you export and reimport

the database, the private markings are lost, since database entries are not
preserved on import/export.  So then I started adding the "private" tag to
private branches.  So now I find that these tags are hard to get rid of.

So perhaps we should go back to the original design?


--
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
P: 778.786.1122
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

http://www.eurotcl.tcl3d.org/ - EuroTcl 2012, July 7-8 , Munich, Germany.
http://www.tcl.tk/community/tcl2012/ - Tcl'2012, Nov 12-16, Chicago, IL, USA.
___
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 code sprint. Was: DRH to be in Munich, Germany July 3rd, 2012

[Richard Hipp]

On Tue, May 15, 2012 at 12:20 PM, Stephan Beal wrote:

>
> Richard Hipp will be in Munich, Germany for a few days in July and has
> graciously[1] offered to host a presentation and/or hacking session with
> regards to sqlite and/or Fossil SCM.
>

My desire is to have a Fossil code-sprint on July 3.  Come and bring your
laptop and be prepared to hack.  I'll have contributor license
agreementson
hand for you to sign if you have not done so already, I will be
handing
out passwords for push privileges on the core Fossil repository, and I will
providing guidance and training to anybody who is interested in how to get
started in hacking Fossil.

Ideas for things to implement at the sprint include:

* WYSIWYG wiki editing
* Web-based content file editing
* User preferences stored in a cookie
* Automatically adjust side-by-side font sizes to fit the screen
* Full text search
* Better labeling of attachments
* Fix the private branch mechanism to make it easy to publish a private
branch
* Automated self-test

The above list will likely grow.  So if you are planning to be in the
Munich area on July 3 please stop by   Contact Stephen Beal for information
on the venue.

If this code sprint works out - if people show interest and useful work
gets done - then I'll be happy to have follow-ups in other locations and on
other continents.

-- 
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] "losing" history in private branch merge?

[Richard Hipp]

So, clearly, I just need to revisit the whole "private branch" concept

As originally implemented, private branches were just a marking in the
database.  But then somebody (aku?) pointed out that if you export and
reimport the database, the private markings are lost, since database
entries are not preserved on import/export.  So then I started adding the
"private" tag to private branches.  So now I find that these tags are hard
to get rid of.

So perhaps we should go back to the original design?

-- 
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] "losing" history in private branch merge?

[org.fossil-scm.fossil-users]

On Fri, 25 May 2012 17:41:44 +
 wrote:

> On Fri, 25 May 2012 13:34:54 -0400
> Richard Hipp  wrote:
> 
> > I don't think so, not other than checking each one out and
> > recommitting them one by one.  To do otherwise would be changing the
> > history of the project, which Fossil does not allow (by design).
> 
> That's fine.
> 
> Which commands should I use to do the above? I want to avoid screwing
> things up even further, so I'd like to be sure...

Expecting disaster, I made a copy of the database.

I shunned the merge commit from the web interface. Then, for each
commit in the private branch, I attempted to merge the private commit
with the current trunk (which had not changed since the start of the
private branch). Within two commits, I somehow had merge conflicts (how
is that even possible?) and files from a commit that I'd not yet merged.

Assuming I'd done something wrong, I went back to the original copy of
the database and tried again. Same result. I give up.

___
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] "losing" history in private branch merge?

[Scott Robison]

On Fri, May 25, 2012 at 12:26 PM, Nolan Darilek  wrote:
> Shame, I actually kind of liked that individual commits were preserved.
> Squashing and such was part of why I left Git. History should be preserved,
> whether you are working alone in private or in the open.

History is preserved in your private branch for your private perusal,
isn't it? To borrow some C++ lingo, it sounds like what you're looking
for might be better called a 'protected' branch. Or if necessary
disable auto-sync and publicly branch until you're done with it,
optionally on another clone of the repository. Or probably other
things I can't think of at the moment.

The desired functionality is there, just not the way you were
expecting it, probably.

Note: I don't mean for the above to come off terse or rude or
condescendingly. Just observing some other possible solutions that
haven't been mentioned yet that will publicly preserve history in a
way that works with the existing system.

SDR
___
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] "losing" history in private branch merge?

[Nolan Darilek]

On 05/25/2012 11:10 AM, org.fossil-scm.fossil-us...@io7m.com wrote:
That's one interpretation of private, yes. I took it to mean that the 
branch wouldn't be synced, or visible, on any remotes. I don't think 
that necessarily implies coalescing commits like that... If it's not 
possible, I can live with it, I'll just switch to only using public 
branches.




This was my interpretation of how the feature worked as well, having 
never used it before.


Shame, I actually kind of liked that individual commits were preserved. 
Squashing and such was part of why I left Git. History should be 
preserved, whether you are working alone in private or in the open.

___
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] Signing

[Ron Wilson]

On 5/23/12, Lluís Batlle i Rossell  wrote:
> But what would you sign? The original tree? Comment updates? Tags? Dates?
> All
> until some point? What on later changes to the checkin?

To answer your last question, you can only sign what exists at the
time of the signing.

In the simplest case, just sign the Manifest artifact. Each signature
would be a Control artifact with a Signature tag, a Singer tag and a
Signer-comment tag, both refering to the Manifest artifact (or maybe
Signer-comment references its containing artifact). The signature
would be on the Manifest artifact, the Signer, the signing date and
the signer comment. Any number of signatures could be applied to the
Manifest.

On top of that, could support signing one or more of the existing
signatures at the time of signing.

For simplicity, a signature Control Artifact would only contain a
single set of signing tags and refer to only a single Manifest and the
list of other signatures for the same Manifest that are being "over
signed". This way the entire target artifacts could be signed

If we then want to include other tags, I would suggest that the
signing artifact include the tages (and their values) being signed.
This way, the signer can simply view the effective tag values,
optionally edit them, then submit the signature including the
"approved" tags and values.

Unfortunately, signing tags then creates 2 classes of tags and
associated complications. When fetching the contents of a commit, it
should be moderately easy to choose by querying on the signer., or
pressence of a signature. However, Fossil propagates tags based on
most recent. Even simply selecting on most recently signed would
likely add a very significant amount of complexity.
___
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] "losing" history in private branch merge?

[Lluís Batlle i Rossell]

On Fri, May 25, 2012 at 01:53:23PM -0400, Richard Hipp wrote:
> On Fri, May 25, 2012 at 1:51 PM, Lluís Batlle i Rossell 
> wrote:
> > Ah, I thought that branches could be made back public easily. I never used
> > privated branches still, so I have zero practise with them.
> >
> > As for the tag, Why it does not work as in an inherited tag?
> >
> 
> The "private" tag is hard-coded onto every check-in of a private branch.
> You can override the tag later.  But there is still a new instance of the
> tag on every check-in and each new instance has to be cancelled separately.

Sorry for the misunderstanding; for 'why', I meant if it can be changed to use
an inherited tag, instead of hardcoding it at every checkin.

What do you think of supporting some way of making a private branch public?

Thank you,
Lluís.
___
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] "losing" history in private branch merge?

[Richard Hipp]

On Fri, May 25, 2012 at 1:51 PM, Lluís Batlle i Rossell wrote:

> On Fri, May 25, 2012 at 01:49:06PM -0400, Richard Hipp wrote:
> > On Fri, May 25, 2012 at 1:42 PM, Lluís Batlle i Rossell <
> vi...@viric.name>wrote:
> >
> > > >
> > > > I don't think so, not other than checking each one out and
> recommitting
> > > > them one by one.  To do otherwise would be changing the history of
> the
> > > > project, which Fossil does not allow (by design).
> > >
> > > Couldn't the branch be made public just before merging?
> > >
> >
> >
> > There is no easy way to make a branch public.  It *might* work to go
> > through an cancel the "private" tag on each check-in of the branch, then
> > run "rebuild".  Emphasis is on the word "might" because I have never
> > actually tried to do that.  And, there is no way that I know of to cancel
> > the tag on all checkins of a branch all at once - you'd have to do them
> one
> > by one.
>
> Ah, I thought that branches could be made back public easily. I never used
> privated branches still, so I have zero practise with them.
>
> As for the tag, Why it does not work as in an inherited tag?
>

The "private" tag is hard-coded onto every check-in of a private branch.
You can override the tag later.  But there is still a new instance of the
tag on every check-in and each new instance has to be cancelled separately.


>
> Thank you,
> Lluís.
> ___
> 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] "losing" history in private branch merge?

[Lluís Batlle i Rossell]

On Fri, May 25, 2012 at 01:49:06PM -0400, Richard Hipp wrote:
> On Fri, May 25, 2012 at 1:42 PM, Lluís Batlle i Rossell 
> wrote:
> 
> > >
> > > I don't think so, not other than checking each one out and recommitting
> > > them one by one.  To do otherwise would be changing the history of the
> > > project, which Fossil does not allow (by design).
> >
> > Couldn't the branch be made public just before merging?
> >
> 
> 
> There is no easy way to make a branch public.  It *might* work to go
> through an cancel the "private" tag on each check-in of the branch, then
> run "rebuild".  Emphasis is on the word "might" because I have never
> actually tried to do that.  And, there is no way that I know of to cancel
> the tag on all checkins of a branch all at once - you'd have to do them one
> by one.

Ah, I thought that branches could be made back public easily. I never used
privated branches still, so I have zero practise with them.

As for the tag, Why it does not work as in an inherited tag?

Thank you,
Lluís.
___
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] "losing" history in private branch merge?

[Richard Hipp]

On Fri, May 25, 2012 at 1:42 PM, Lluís Batlle i Rossell wrote:

> >
> > I don't think so, not other than checking each one out and recommitting
> > them one by one.  To do otherwise would be changing the history of the
> > project, which Fossil does not allow (by design).
>
> Couldn't the branch be made public just before merging?
>


There is no easy way to make a branch public.  It *might* work to go
through an cancel the "private" tag on each check-in of the branch, then
run "rebuild".  Emphasis is on the word "might" because I have never
actually tried to do that.  And, there is no way that I know of to cancel
the tag on all checkins of a branch all at once - you'd have to do them one
by one.


> ___
> 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] "losing" history in private branch merge?

[Lluís Batlle i Rossell]

On Fri, May 25, 2012 at 01:34:54PM -0400, Richard Hipp wrote:
> On Fri, May 25, 2012 at 1:09 PM, wrote:
> 
> > On Fri, 25 May 2012 16:10:44 +
> >  wrote:
> >
> > > On Fri, 25 May 2012 11:53:35 -0400
> > > Richard Hipp  wrote:
> > >
> > > > On Fri, May 25, 2012 at 11:42 AM,
> > > > wrote:
> > > > > Is it possible to avoid squashing all private commits into one?
> > > > >
> > > >
> > > > The branch is private.  If all the individual commits where pushed
> > > > out to the world, it wouldn't be private any more and the whole
> > > > purpose of having a private branch would be defeated, no?
> > > >
> > >
> > > That's one interpretation of private, yes. I took it to mean that the
> > > branch wouldn't be synced, or visible, on any remotes. I don't think
> > > that necessarily implies coalescing commits like that...
> > >
> > > If it's not possible, I can live with it, I'll just switch to only
> > > using public branches.
> >
> > Is it possible to get those commits into trunk in any way? Losing the
> > details isn't acceptable (due to my misunderstanding of exactly what
> > a private branch entailed).
> >
> 
> I don't think so, not other than checking each one out and recommitting
> them one by one.  To do otherwise would be changing the history of the
> project, which Fossil does not allow (by design).

Couldn't the branch be made public just before merging?
___
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] "losing" history in private branch merge?

[org.fossil-scm.fossil-users]

On Fri, 25 May 2012 13:34:54 -0400
Richard Hipp  wrote:

> I don't think so, not other than checking each one out and
> recommitting them one by one.  To do otherwise would be changing the
> history of the project, which Fossil does not allow (by design).

That's fine.

Which commands should I use to do the above? I want to avoid screwing
things up even further, so I'd like to be sure...
___
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] "losing" history in private branch merge?

[Richard Hipp]

On Fri, May 25, 2012 at 1:09 PM, wrote:

> On Fri, 25 May 2012 16:10:44 +
>  wrote:
>
> > On Fri, 25 May 2012 11:53:35 -0400
> > Richard Hipp  wrote:
> >
> > > On Fri, May 25, 2012 at 11:42 AM,
> > > wrote:
> > > > Is it possible to avoid squashing all private commits into one?
> > > >
> > >
> > > The branch is private.  If all the individual commits where pushed
> > > out to the world, it wouldn't be private any more and the whole
> > > purpose of having a private branch would be defeated, no?
> > >
> >
> > That's one interpretation of private, yes. I took it to mean that the
> > branch wouldn't be synced, or visible, on any remotes. I don't think
> > that necessarily implies coalescing commits like that...
> >
> > If it's not possible, I can live with it, I'll just switch to only
> > using public branches.
>
> Is it possible to get those commits into trunk in any way? Losing the
> details isn't acceptable (due to my misunderstanding of exactly what
> a private branch entailed).
>

I don't think so, not other than checking each one out and recommitting
them one by one.  To do otherwise would be changing the history of the
project, which Fossil does not allow (by design).



>
> ___
> 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] "losing" history in private branch merge?

[org.fossil-scm.fossil-users]

On Fri, 25 May 2012 10:18:34 -0700
Matt Welland  wrote:

> On Fri, May 25, 2012 at 9:10 AM,
> wrote:
> 
> > On Fri, 25 May 2012 11:53:35 -0400
> > Richard Hipp  wrote:
> >
> > > On Fri, May 25, 2012 at 11:42 AM,
> > > wrote:
> > > > Is it possible to avoid squashing all private commits into one?
> > > >
> > >
> > > The branch is private.  If all the individual commits where pushed
> > > out to the world, it wouldn't be private any more and the whole
> > > purpose of having a private branch would be defeated, no?
> > >
> >
> > That's one interpretation of private, yes. I took it to mean that
> > the branch wouldn't be synced, or visible, on any remotes. I don't
> > think that necessarily implies coalescing commits like that...
> >
> > If it's not possible, I can live with it, I'll just switch to only
> > using public branches.
> 
> 
> It sounds like the request would be able to switch a branch from
> private to public. That seems like it would be a very powerful
> feature (assuming it is not already possible?).

Yeah, I think the direct approach would be (if the feature existed):

1. Undo the "merge" commit (perhaps by shunning).
2. Mark the private branch as public.
3. Merge again.


___
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] "losing" history in private branch merge?

[Matt Welland]

On Fri, May 25, 2012 at 9:10 AM, wrote:

> On Fri, 25 May 2012 11:53:35 -0400
> Richard Hipp  wrote:
>
> > On Fri, May 25, 2012 at 11:42 AM,
> > wrote:
> > > Is it possible to avoid squashing all private commits into one?
> > >
> >
> > The branch is private.  If all the individual commits where pushed
> > out to the world, it wouldn't be private any more and the whole
> > purpose of having a private branch would be defeated, no?
> >
>
> That's one interpretation of private, yes. I took it to mean that the
> branch wouldn't be synced, or visible, on any remotes. I don't think
> that necessarily implies coalescing commits like that...
>
> If it's not possible, I can live with it, I'll just switch to only using
> public branches.


It sounds like the request would be able to switch a branch from private to
public. That seems like it would be a very powerful feature (assuming it is
not already possible?).


>
> ___
> 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] "losing" history in private branch merge?

[org.fossil-scm.fossil-users]

On Fri, 25 May 2012 16:10:44 +
 wrote:

> On Fri, 25 May 2012 11:53:35 -0400
> Richard Hipp  wrote:
> 
> > On Fri, May 25, 2012 at 11:42 AM,
> > wrote:
> > > Is it possible to avoid squashing all private commits into one?
> > >
> > 
> > The branch is private.  If all the individual commits where pushed
> > out to the world, it wouldn't be private any more and the whole
> > purpose of having a private branch would be defeated, no?
> > 
> 
> That's one interpretation of private, yes. I took it to mean that the
> branch wouldn't be synced, or visible, on any remotes. I don't think
> that necessarily implies coalescing commits like that...
> 
> If it's not possible, I can live with it, I'll just switch to only
> using public branches.

Is it possible to get those commits into trunk in any way? Losing the
details isn't acceptable (due to my misunderstanding of exactly what
a private branch entailed).

___
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] "losing" history in private branch merge?

[org.fossil-scm.fossil-users]

On Fri, 25 May 2012 11:53:35 -0400
Richard Hipp  wrote:

> On Fri, May 25, 2012 at 11:42 AM,
> wrote:
> > Is it possible to avoid squashing all private commits into one?
> >
> 
> The branch is private.  If all the individual commits where pushed
> out to the world, it wouldn't be private any more and the whole
> purpose of having a private branch would be defeated, no?
> 

That's one interpretation of private, yes. I took it to mean that the
branch wouldn't be synced, or visible, on any remotes. I don't think
that necessarily implies coalescing commits like that...

If it's not possible, I can live with it, I'll just switch to only using
public branches.


___
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] "losing" history in private branch merge?

[Richard Hipp]

On Fri, May 25, 2012 at 11:42 AM, wrote:

> Hello.
>
> 1) I created a private branch, made several commits, and then merged the
> private branch with the current trunk. Rather than seeing the commits
> I made on the private branch in the timeline for the trunk, I only see
> the one large commit resulting from accumulating all the smaller commits
> into one when merging.
>
> Is it possible to avoid squashing all private commits into one?
>

The branch is private.  If all the individual commits where pushed out to
the world, it wouldn't be private any more and the whole purpose of having
a private branch would be defeated, no?



>
> 2) Additionally, as auto-sync was enabled, the large commit was pushed
> to a remote. I realize it's not possible to rewrite history (nor would I
> want to), but is there some way to push any changes I make whilst trying
> to sort out item 1 above (so that the private commits are visible)?
> ___
> 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] "losing" history in private branch merge?

[org.fossil-scm.fossil-users]

Hello.

1) I created a private branch, made several commits, and then merged the
private branch with the current trunk. Rather than seeing the commits
I made on the private branch in the timeline for the trunk, I only see
the one large commit resulting from accumulating all the smaller commits
into one when merging.

Is it possible to avoid squashing all private commits into one?

2) Additionally, as auto-sync was enabled, the large commit was pushed
to a remote. I realize it's not possible to rewrite history (nor would I
want to), but is there some way to push any changes I make whilst trying
to sort out item 1 above (so that the private commits are visible)?
___
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] Zip command creates zip files that confuse Windows XP

[Pavel Aronsky]

A quick research showed that there were indeed changes in zip format,
not supported by WinXP Explorer but supported in Vista.
ZIP64 is one of these.
(http://en.wikipedia.org/wiki/Zip_%28file_format%29#Structure)

So, this probably is just WinXP showing its age.

Thanks,
-- pa

-
From: Richard Hipp <>
Date: Wed, 23 May 2012 14:04:35 -0400
Subject: Re: [fossil-users] Zip command creates zip files that confuse
Windows XP

On Wed, May 23, 2012 at 1:56 PM, Pavel <> wrote:

Has anyone noticed this?

When Explorer of WinXP opens a zip created by fossil zip export,
it shows a zero-sized file for every subfolder in the zip.

Explorer of Win7 does not have this problem, and neither does 7z.
However, would it be possible to fix this annoyance for remaining XP users?


Fixing it would probably be very simple, if we knew what was wrong.
Probably there is something in the file header that Fossil generates
that WinXP Explorer does not like or is misinterpreting.  But what
exactly is that something?  Can you do some detective work to try to
figure out what it is about Fossil-generated ZIP archives that WinXP
explorer does not like?  (I don't have a copy of WinXP to experiment
with.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users