Emacspeak discussion list

[Robert Melton <lists AT robertmelton.com>]

I think you grasp the issue.  Additionally, you are right that if I modified 
files that get moved except the binary (like a change to cloud-swiftmac for 
example) stuff could get ugly quick.  

On the submodule / subtree, please no, the level of pain with submodules in 
my experience is not at all worth the functionality. 

The real solution to keep the emacspeak repo relatively up to date and most 
people should just use it, and if you are using my swiftmac repo you are 
expected to be a developer or advanced userr.  I think we got to the right 
end point.  :)


> On Jan 9, 2024, at 18:38, Tim Cross (via emacspeak Mailing List) 
> <emacspeak AT emacspeak.net> wrote:
> 
> 
> Agree. Only mentioned the use of the environment variable in the context
> of installing the most recent swiftmac server from Robert's own github
> rather than the one actually in the emacspeak tree itself. My
> understanding (which could easily be wrong) was that the issue was with
> getting a copy from RObert's private git repo and having that installed
> inside the Emacspeak install, replacing the version included in
> emacspeak.
> 
> Of course, this also has other issues not yet discussed. For example,
> when someone has installed from Robert's private repo and copied the
> server into the emacspeak tree, then enxt time the user goes to pull
> from the emacspeak repo, git will tell them they need to either commit
> or stash their changes. THis will likely cause all sorts of problems for
> users as committing will mean their local emacspeak copy has diverged
> from the main emacspeak repo.
> 
> I do wonder if there is a better way of doing this. For example, I think
> it might be possible for emacspeak to include Robert's swiftmac
> repository as a sub repository within the emacspeak repository. When
> people do a checkout of the emacspeak repository, they would get that
> repository as well, but as it is actually its own repository, they could
> also switch its branch, lets say to the development branch. This would
> avoid all the current issues and allow those who want to to run Robert's
> bleeding edge development version while others just stick with the
> stable version, plus Robert wouldn't need to do pushes from his repo
> into the emacspeak repo. However, I've only read about using this
> sub-repo spproach and don't know what the hidden complexities/issues are
> or what other limitations this could introduce. 
> 
> Date: Wed, 10 Jan 2024 10:38:43 +1100
> Emacspeak discussion list -- emacspeak AT emacspeak.net
> To unsubscribe send email to:
> emacspeak-request AT emacspeak.net with a subject of: unsubscribe