Fossil Forum

working with multiple remotes?
Login

working with multiple remotes?

(1) By Alfred M. Szmidt (ams) on 2020-06-04 08:01:52 [source]

Hello,

I am trying to figure out a workflow where I have a one upstream repository, to which I cannot push.   So I clone this, and work on it locally.

So far so good, but what if I want to work on this forked (I don't like this word, but it describes best what I want to achieve) repository from multiple other machines?    I still want to get changes from the original upstream repository, but keep my own changes in a single place.

The way that I'm thinking that this might work is to put the "fork" on a server, from which I will do my clones and pushes towards a fork/trunk branch kinda thing.  On the server, one would then update that periodically from upstream, but I slightly escapes me how? 


/Alfred

(2.1) By Alfred M. Szmidt (ams) on 2020-06-04 09:10:31 edited from 2.0 in reply to 1 [link] [source]

Here is what I am thinking.  First we clone the original remote repository O on server F (possibly also disabling auto-push),

  fossil clone O O.fossil

On any local machines, we clone it from server F and switch to the "forked" branch:

  fossil clone F F.fossil 
  fossil open F.fossil F/trunk

Here we can work on our F/trunk branch, and merge changes back from the official trunk branch.

Then to update the F copy -- which could I think be done on the local machines too and then synced to the F server?

  fossil sync O -R O.fossil

Would this be a sensible workflow?  Are there any caveats that I am missing?

(3) By Stephan Beal (stephan) on 2020-06-04 10:44:32 in reply to 2.1 [link] [source]

Here is what I am thinking...

FWIW, that sounds to me like it could/should work. If by F/trunk you mean the logical trunk, named something othef than "trunk" then that wouldn't be a problem until/unless O also uses that branch name.

Related: the main-branch settings tells fossil what the repo's main branch's name is (default = trunk):

https://fossil-scm.org/fossil/help?cmd=main-branch

That might be useful for your F copy.

(4) By Alfred M. Szmidt (ams) on 2020-06-04 12:39:05 in reply to 3 [link] [source]

Yes, exactly F/trunk would be the logical branch name for the forked trunk.

I do have a small worry what will happen to wiki pages, tickets, and such things.

The main-branch setting will be very useful, thank you.

(5) By Stephan Beal (stephan) on 2020-06-04 13:55:20 in reply to 4 [link] [source]

Wikis use a last-edit-wins approach, so... last one wins. All edits are retained in the history, and there's nothing in the data model which prohibits wikis from branching and merging, but no UI has ever been added to enable those. Embedded docs are generally a better doc format because they're part of the main versioned state, including the ability to branch and merge. With the new fileedit page, those can even be edited online.

All additions to tickets are applied, unless i am very sorely mistaken, in the order of their timestamp, so ticiets aren't likely to be a problem for you.

(6) By Alfred M. Szmidt (ams) on 2020-06-04 16:13:55 in reply to 3 [link] [source]

When setting main-branch, is the intention that when doing a "fossil open" that the checked out copy will be on that branch?  The current behaviour seems to just default to trunk.

(7) By Stephan Beal (stephan) on 2020-06-04 19:19:39 in reply to 6 [link] [source]

When setting main-branch, is the intention that when doing a "fossil open" that the checked out copy will be on that branch?

Kinda...

https://fossil-scm.org/fossil/file?udc=1&ln=3054-3058&ci=1243bf39996b8a65&name=src%2Fdb.c

If you specify a version on the command line, it uses that one's branch. If you have a main-branch set but you have not checked in anything to that branch then... i'm not clear what should happen. Presumably, in your case, that branch has never been committed to, so that branch does not actually exist yet, per se, in the SCM history.

Aha... open delegates most of its work to checkout, and checkout, if it cannot find the given version, will fail fatally.

If called like:

fossil open /path/to/repo.fsl

IF the repo has any checkins listed in the timeline, that translates to:

fossil open /path/to/repo.fsl MAIN-BRANCH

Which is then delegated to:

fossil checkout MAIN-BRANCH

If the repo has no checkins listed in the timeline (event table) then checkout will, instead of a version, get passed the --latest flag, which seems to be semantically equivalent to a version of tip.

So...

In your case, if your F/trunk branch has never actually been created (only referenced via main-branch), then i would expect (based on a casual reading of the code) open (via checkout) to fail fatally with a message that F/trunk does not refer to a UUID. If it has been created then i expect open to leave (pun not intended) you in that branch.

(8) By Alfred M. Szmidt (ams) on 2020-06-05 19:18:26 in reply to 7 [link] [source]

Hm.  So I have a remote repository, F, in that I have set main-branch to F/trunk.  I then do,

  fossil clone F F.fossil
  fossil open F.fossil

F contains a branch called F/trunk, and has commits on it.  This still opens trunk, and not the main-branch (F/trunk) that was set on the remote repository?

(9) By Stephan Beal (stephan) on 2020-06-05 21:13:30 in reply to 8 [link] [source]

that was set on the remote repository?

That's a local config option, not a project-level option. According to src/configure.c, it's not part of the syncable state.

(10) By anonymous on 2020-06-05 21:25:45 in reply to 8 [link] [source]

Confirmed. The local main-branch setting is not cloned.

Below is a repro script. This seems to be not an issue when doing a file-clone as opposed to network-clone.

mkdir testrepo
cd testrepo
fossil init testrepo.fossil
fossil open testrepo.fossil
echo "test">f.txt
fossil add f.txt
MAINBRANCH=newtrunk
fossil commit -m "added f.txt" --branch $MAINBRANCH

fossil branch
fossil set main-branch newtrunk
echo "INFO: testrepo main-branch: '" `fossil set main-branch` "'"
fossil close

fossil server testrepo.fossil --port 8888 &
echo "$!" >fossil.pid

mkdir testclone
cd testclone
fossil clone http://localhost:8888 testclone.fossil
fossil open testclone.fossil

fossil branch
echo "INFO: clonerepo main-branch: '" `fossil set main-branch` "'"

curbranch=`fossil branch | grep '^* '`
[ "$curbranch" == "* $MAINBRANCH" ] || echo "ERROR: cloned main-branch setting is incorrect." >&2  
fossil close

cd ..
kill `cat fossil.pid`
rm -rf testclone
cd ..
rm -rf testrepo


In my test this reports the "ERROR:".

(11) By anonymous on 2020-06-06 16:35:15 in reply to 8 [link] [source]

I believe this is supposed to be a syncable option. It has project-level relevance (just as "comment-format" is, for example).

The patch below would enable the remote sync of main-branch setting.

Index: src/configure.c
==================================================================
--- src/configure.c
+++ src/configure.c
@@ -148,10 +148,11 @@
   { "parent-project-name",    CONFIGSET_PROJ },
   { "hash-policy",            CONFIGSET_PROJ },
   { "comment-format",         CONFIGSET_PROJ },
   { "mimetypes",              CONFIGSET_PROJ },
   { "forbid-delta-manifests", CONFIGSET_PROJ },
+  { "main-branch",            CONFIGSET_PROJ },
 
 #ifdef FOSSIL_ENABLE_LEGACY_MV_RM
   { "mv-rm-files",            CONFIGSET_PROJ },
 #endif

(12.1) By Stephan Beal (stephan) on 2020-06-06 16:47:02 edited from 12.0 in reply to 11 [link] [source]

+ { "main-branch", CONFIGSET_PROJ },

It's not a bug - that's not synced by design.

(13) By anonymous on 2020-06-06 17:12:35 in reply to 12.1 [link] [source]

It's not a bug - that's not synced by design.

It's not clear from your statement, what's the reasoning for excluding "main-branch" setting. The way I read it, you suggest that there is a specific consideration for excluding this setting.

(14) By Stephan Beal (stephan) on 2020-06-06 17:22:10 in reply to 13 [link] [source]

It's not clear from your statement, what's the reasoning for excluding "main-branch" setting. The way I read it, you suggest that there is a specific consideration for excluding this setting.

Pardon my previous brevity - working from a tablet makes long/detailed responses tedious.

i don't know the reasoning of whoever initially added that setting, but after seeing that it was defined as un-syncable it became clear to me that i would not want someone else defining what should be the "main" branch on my local copy of a repo. e.g. if i'm working primarily on a long-lived branch other than the main trunk of some project i've forked, i don't want someone else's idea of "main branch" interfering with that.

i can understand why a project would want to define this at the project level, but sympathize more with people who want to set it independently of the project they're synching from. We can't give "main-branch" two different meanings, so my preference would be to leave it how it is - not synced.

(18) By anonymous on 2020-06-06 18:27:59 in reply to 14 [link] [source]

i don't know the reasoning of whoever initially added that setting

Thanks for describing your understanding of this.

Here's how this setting is defined:

The "main-branch" setting:
    The value is the primary branch for the project.

That is the "main-branch" is a project-level setting. It's not meant to be flipped for convenience. There are other equally project-level settings yet which are sync'able.

(20) By Stephan Beal (stephan) on 2020-06-06 20:08:51 in reply to 18 [link] [source]

The "main-branch" setting: The value is the primary branch for the project.

That is the "main-branch" is a project-level setting.

That's certainly the implication of that description, but the description might not have initially been intended to mean "project" as an "project-wide," but "project" as in "this copy of the project." i can't say for sure - it was not my addition.

There are other equally project-level settings yet which are sync'able.

One example is the new fileedit-glob. It's conceptually a project-level setting but if it's made syncable or versionable then someone else may change the default behaviour of someone else's repo, perhaps inadvertently, and, as Egon Spengler put it, "that would be bad."

i think what it comes comes down to is whether or not the changing of the preference could change how someone else's copy of a repo behaves, possibly without them knowing/realizing/desiring it. Making main-branch sync definitely falls into that category of change.

(25) By anonymous on 2020-06-06 22:49:21 in reply to 13 [link] [source]

It's not clear from your statement, what's the reasoning for excluding "main-branch" setting.

To me, it makes sense that the main-branch setting be local-only. At least by how I understand branch naming in Fossil.

I may be wrong, but as I understand Fossil branch naming, a branch begins with a commit tagged with a branch=Name propagating tag. So, any sequence of commits that is not otherwise named by a branch tag is named by the value of main-branch. (When a commit is made, it inherits its parent's branch, unless it is tagged with a branch tag.)

Usually, this "nameless" branch starts with the "Initial empty commit", which, when created, has no branch tag. By default, Fossil displays the name of this branch as "trunk". If you set main-branch, then that is used instead of trunk.

If you tag the initial empty commit with a propagating branch tag, then (1) all those "trunk" commits will become members of this new, named branch, and (2) the main-branch setting will, effectively, be ignored.

(Unless your repo has more than 1 trunk. Then the branch tag will, of course, only affect one of those trunks.)

Again, I may be misunderstanding how Fossil branching works. But, if I'm correct, then the main-branch setting is only cosmetic.

Either way, if you want a project-wide main branch name, try:

    fossil amend --branch NAME HASH

where HASH is the commit ID of the first commit on "trunk".

(15) By Alfred M. Szmidt (ams) on 2020-06-06 17:25:46 in reply to 12.1 [link] [source]

Why is it not synced by design?  It seems that the whole point of the setting is lost otherwise?

Isn't it also slightly confusing if cloning from a file, sets it accordingly.  While from a URL it does not?

(16) By Stephan Beal (stephan) on 2020-06-06 17:31:37 in reply to 15 [link] [source]

It seems that the whole point of the setting is lost otherwise?

One use of the setting is lost, yes, but another (see my previous response) is not. There's no objective way to decide which of those two uses is more valuable, but if we suddenly make it syncable, after it previously was not, we irrevocably break the other use (with no workaround). If we leave it unsyncable then at least the other use continues to behave how it historically has.

Isn't it also slightly confusing if cloning from a file, sets it accordingly. While from a URL it does not?

That feels like a bug to me. Cloning "should" (IMHO) behave identically regardless of the way the source is accessed.

(17) By Alfred M. Szmidt (ams) on 2020-06-06 17:39:42 in reply to 16 [link] [source]

Would a default-main-branch, which is syncable, make sense?  The semantics would be that if main-branch is empty, use default-main-branch.  Otherwise use main-branch -- main-branch would be project specific.  This would keep everyone happy I think?

(19) By Stephan Beal (stephan) on 2020-06-06 20:02:17 in reply to 17 [link] [source]

The semantics would be that if main-branch is empty, use default-main-branch.

This would keep everyone happy I think?

i'm not personally averse to it, but i wonder if it's really needed. So far it hasn't been, and your use case can be implemented without it: simply set main-branch to F/trunk on the clones which need it?

(21) By Alfred M. Szmidt (ams) on 2020-06-06 20:17:05 in reply to 19 [link] [source]

I'd need to set that each time I, or someone else, clones the repository.  If another person clones the F repository, they also have to explicitly know that they need to change the main branch before the can work against it, and if they accidentally push any changes those will end up on the original trunk branch -- causing all kinds of messy behavior.

(22) By Stephan Beal (stephan) on 2020-06-06 20:37:12 in reply to 21 [link] [source]

Quoted from my response to our anonymous poster:

i think what it comes comes down to is whether or not the changing of the preference could change how someone else's copy of a repo behaves, possibly without them knowing/realizing/desiring it. Making main-branch sync definitely falls into that category of change.

Changing its behaviour, or changing the value of main-branch after it is made synchable, could indeed lead to...

causing all kinds of messy behavior.

Potentially repeatedly, as an admin changes their mind about the main branch name.

i'm not fundamentally against adding a specifically synchable setting which acts as the project-wide default for main-branch (with the latter taking precedence), but (again) i'm not convinced that it's needed, nor am i convinced that it wouldn't have fallout of its own when a project admin changes it willy-nilly and thereby changes default behaviours in downstream clones which aren't expecting it.

That said, if someone else wants to implement it, and update the... 7(?)... places which check main-branch, i won't fight it.

(24) By Alfred M. Szmidt (ams) on 2020-06-06 20:43:44 in reply to 22 [link] [source]

I'll see about living with the status quo.  If it annoys me enough, I'll post a patch. :-)

(23) By Alfred M. Szmidt (ams) on 2020-06-06 20:38:34 in reply to 17 [link] [source]

Another way of doing this, I think, would be to have a default-trunk-name, which would be used everywhere where "trunk" is used?  Not sure what would be the most sensible.