This sounds familiar, a "pocket-sync" protocol or "virus-taxi" :)
Needs a robust anti-virus for protection.
If I understood it correctly, your main criteria are:
1) One flash drive -- use of flash drive to keep all "master" project
repos on it
2) Many PCs -- work on any project at many field-PC's
3) Two-way sync -- sync project repo changes across all involved PC
without the need for network/internet
4) Extra backup -- have a backup for the project repos
5) Keep it tidy :) -- leave no project files behind on the PCs
Fossil is definitely suitable for such a "pocket" solution as it does
not need an installation and can be run directly.
Your case is a good example for DVCS use, yet lacking internet/network
the only sync option is via local file-system.
As was already mentioned, using the flash drive for both repos and
work would make this self-contained.
This way all changes are always on the flash drive, so the sync is
kinda implicit.
To enforce the central role of the flash drive, you may want to setup
some kind of a "workspace" on it, maybe have it mapped to the same
drive-letter on all of the PCs (with `subst` or `net use` command).
Also add some scripts to assist you in setup and sync.
For this to work out, you may need to have the flash drive partition
set up with Everyone:Read/Write/Delete NTFS security, so that the
potentially different user-SIDs on the PCs could write to the flash
drive. OR, well, have it formatted FAT32.
Also, you probably want to have the actual "master" repos set up on
your own "trusted" PC, instead of the flash dirve for obvious reasons
so it does not get lost-in-action :)
POSSIBLE WORKFLOW
plug to "trusted" PC:
1) setup actual "master" Fossil repos on your own "trusted" PC, add
users, serve the repos if desired, backup appropriately
2) setup the flash-drive, format, populate with needed tools, scripts etc.
3) setup the flash-bound workspace environment
4) sync workspace with the "trusted" repos
once plugged to any field-PC:
5) setup the flash-bound workspace environment
6) do work in the workspace, commit as needed (implicitly to the flash)
7) if can connect to the "trusted" PC, sync the repos
once back at "trusted" PC:
8) setup the flash-bound workspace environment
9) sync workspace and "trusted" repos
POSSIBLE WORKSPACE
\devel
|-env
|-fossils
|-tools
|-projects
|-builds
Each project has its own repo in fossils:
fossils\projectX.fossil
Project work-copies are fetched from resp. fossil and created as
needed (one only or per revision, PC, case etc.), commit/branch as
needed:
projects\projectX-try-something
Preferrably do out-of-source builds, so it's easier to track source
changes, or potentially re-assign build dir to host's HDD for speed:
builds\projectX-try-something
LOGICAL ENV
DEVENV => %DEVDRIVE%\env
DEVFOSSILS => %DEVDRIVE%\fossils
DEVPROJECTS => %DEVDRIVE%\projects
DEVBUILDS => %DEVDRIVE%\builds
Environment variables are set up from script (shortcut), which would
assign DEVDRIVE and open a CMD prompt in the workspace:
\devel\env\setupdev.cmd
DEVDRIVE is basically a substitute for FLASHDIRVE:\devel, whatever
letter auto-assigned to the flash drive by the system.
Preferably DEVDRIVE should be set the same on all PC's, perhaps some
least used bottom letters (??W:)
This allows re-use of the project work-copies on different field-PCs,
as Fossil saves path of the opened Fossil repo.
TWO-WAY REPO SYNC
field-PC to flash-"master":
it's implicit, just commit and update as needed from within the
flash-bound workspace.
flash-"master" to "trusted"-PC:
It's bound to the way how the flash-"master" was cloned (//file, or
URL), it should be saved in the repo.
Preferably it's via URL, so you may sync even while on a field-PC (if
networked):
fossil sync
EXAMPLE SESSION
- plug the flash into a field-PC, open CMD prompt, run setup:
F:\devel\env\setupdev
- this assigns the DEVDRIVE, sets up environment, changes path to DEVPROJECTS:
W:\projects
- checkout a working-copy of a project repo
mkdir projectX-try-something
cd projectX-try-something
fossil open "%DEVFOSSILS%\projectX.fossil" revision123
fossil user default %DEVUSER% --user %DEVUSER%
- OR when exists already, sync local if needed
fossil update
- do development, test, commit changes
fossil commit
- done, clean up, deassign the DEVDRIVE, close prompt:
closedev
- plug the flash into "trusted"-PC, open CMD, run setup:
H:\devel\env\setupdev
- this assigns the DEVDRIVE, sets up environment, changes path to DEVPROJECTS:
W:\projects
- sync all repos to "trusted", script that walks through all .fossil
files in DEVFOSSILS and does "fossil sync %TRUSTEDREPOURL%"
syncrepos
THE END :)
That's the general idea, sorry for the long post. It's probably easier
to implement this than describe.
Hope you'd find this useful.
On Fri, Jan 20, 2017 at 3:02 AM, Martin Irvine
<martin_irv...@bigpond.com.au> wrote:
> Hi,
>
>
>
> I am new to Software Configuration Management systems, but am now interested
> in using Fossil. I have been reviewing the documentation on-and-off for a
> few days, and have played with the program a little, but I am still unsure
> how to most appropriately use it to meet my needs, so I would appreciate any
> advice anyone would like to offer on the following use scenario.
>
>
>
> I am working exclusively in Windows environments. I am a sole developer,
> often working on a number of relatively small projects at a time. For the
> time being at least, I do not expect to make much use of forking and
> branching capabilities – I like to think my code development generally
> progresses fairly linearly. But I regularly need to access and update my
> code at a number of usually standalone PCs - that is, they are never
> networked to each other and often do not even have internet access.
>
>
>
> I am hoping that Fossil will assist me in two ways, keeping track of
> milestones in my codebases including providing the ability to easily restore
> a previous version for testing purposes, and also making it as simple as
> possible for me to ensure I always have all versions of the code for every
> project accessible to me when I sit down to work at any particular PC.
>
>
>
> To achieve the second objective, I expect to make a point of always carrying
> a USB Flash Drive with me as I move from PC to PC. I expect this Flash
> Drive should contain a number of repository files, one for each project I am
> concerned with. I expect when I sit down at any particular PC I should be
> able to extract from the relevant repository on this Flash Drive whichever
> version of whichever project I need to access. Similarly, when I “finish”
> working at this PC if I wish to retain any changes I have made I expect I
> should “commit” these changes back to relevant repository on the Flash Drive
> in some way. But the most appropriate way to do all this is unclear to me.
>
>
>
> I understand Fossil is generally intended to work with a local copy of a
> project’s repository on each machine’s local hard disk, and with a master
> repository accessed remotely when required via a network or internet
> connection. In my case, it seems to me the master repository would be the
> relevant repository file on my Flash Drive, but when my Flash Drive is
> plugged into the machine I am working on, the files on it are effectively
> local, not remote. So, when I sit down to work at a PC, should I copy the
> repository file for the project I need to work on onto the PC’s local hard
> drive, then open the version of the code I need to access from this copy of
> the repository, or should I just open the project repository directly from
> my Flash Drive ? Additionally, if I should copy the repository onto the
> local hard disk, should I simply copy the repository file using the
> operating system, or should I use Fossil to clone it to the local hard disk
> (I do not really understand the difference here) ? Then, when I finish
> working at the PC, if I wish to incorporate any changes I have made back
> into the repository on my Flash Drive, should I update this directly into
> the repository on my Flash Drive, or into a copy of the repository on the
> PC’s local hard disk ? If the later, should I then simply copy the updated
> repository file onto my Flash Drive (overwriting the previous repository
> file), or should I “pull” or “push” the changes into the repository file on
> the Flash Drive – can I even do this, when the hard disk based repository
> and the Flash Drive based repository files are effectively both local files
> on the same PC ? I guess I'm getting a bit confused here…
>
>
>
> A possible additional complicating factor in the “right” way to do all this
> is that typically, when I finish working at a PC I often will not want to
> leave a copy of the source code or the repository on the PC (i.e., on a
> customer’s hardware). I understand deleting the local copies of the
> repositories undermines the redundancy and backup benefits of using a
> Distributed SCM system, but I guess I will address this by leaving copies of
> the repositories on my own PCs and also ensuring I regularly make backup
> copies of the repository files on the Flash Drive.
>
>
>
> So any thoughts, experience or advice on the most appropriate way to use
> Fossil in the above scenario would be most welcome, thank you.
>
>
>
>
>
>
> _______________________________________________
> 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
