gmane.comp.version-control.fossil-scm.user

Re: "losing" history in private branch merge?

Gour — 2012-05-25T19:55:38

On Fri, 25 May 2012 15:28:02 -0400
Richard Hipp <drh-CzDROfG0BjIdnm+yROfE0A< at >public.gmane.org> wrote:


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

Re: "losing" history in private branch merge?

Andreas Kupries — 2012-05-25T19:43:57

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

Re: "losing" history in private branch merge?

Richard Hipp — 2012-05-25T19:28:02

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?

Re: "losing" history in private branch merge?

2012-05-25T19:24:15

On Fri, 25 May 2012 17:41:44 +0000
<org.fossil-scm.fossil-users-fAjmDXfYvhs< at >public.gmane.org> wrote:


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.

Re: "losing" history in private branch merge?

Scott Robison — 2012-05-25T18:58:56

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

Re: "losing" history in private branch merge?

Nolan Darilek — 2012-05-25T18:26:17



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.

Re: Signing

Ron Wilson — 2012-05-25T17:59:30

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,

Re: "losing" history in private branch merge?

Lluís Batlle i Rossell — 2012-05-25T17:56:34

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.

Re: "losing" history in private branch merge?

Richard Hipp — 2012-05-25T17:53:23


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.

Re: "losing" history in private branch merge?

Lluís Batlle i Rossell — 2012-05-25T17:51:30

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.

Re: "losing" history in private branch merge?

Richard Hipp — 2012-05-25T17:49:06



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.

Re: "losing" history in private branch merge?

Lluís Batlle i Rossell — 2012-05-25T17:42:11

Couldn't the branch be made public just before merging?

Re: "losing" history in private branch merge?

2012-05-25T17:41:44

On Fri, 25 May 2012 13:34:54 -0400
Richard Hipp <drh-CzDROfG0BjIdnm+yROfE0A< at >public.gmane.org> wrote:


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...

Re: "losing" history in private branch merge?

Richard Hipp — 2012-05-25T17:34:54


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).

Re: "losing" history in private branch merge?

2012-05-25T17:23:35

On Fri, 25 May 2012 10:18:34 -0700
Matt Welland <estiforta-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


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.

Re: "losing" history in private branch merge?

Matt Welland — 2012-05-25T17:18:34



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-RyYwo1q5J+rPvulMB6uEI2D2FQJk+8+b< at >public.gmane.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: "losing" history in private branch merge?

2012-05-25T17:09:02

On Fri, 25 May 2012 16:10:44 +0000
<org.fossil-scm.fossil-users-fAjmDXfYvhs< at >public.gmane.org> wrote:


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).

Re: "losing" history in private branch merge?

2012-05-25T16:10:44

On Fri, 25 May 2012 11:53:35 -0400
Richard Hipp <drh-CzDROfG0BjIdnm+yROfE0A< at >public.gmane.org> 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.

Re: "losing" history in private branch merge?

Richard Hipp — 2012-05-25T15:53:35


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?

"losing" history in private branch merge?

2012-05-25T15:42:37

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)?

Re: Zip command creates zip files that confuseWindows XP

Pavel Aronsky — 2012-05-25T15:09:31

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,