1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
Did a fair amount of testing and bug fixing today.
There is still some buggy behavior around pausing syncing to a remote,
where transfers still happen to it, but I fixed the worst bug there.
Noticed that if a non-bare repo is set up on a removable drive,
its file tree will not normally be updated as syncs come in -- because the
assistant is not running on that repo, and so incoming syncs are not
merged into the local master branch. For now I made it always use bare
repos on removable drives, but I may want to revisit this.
The repository edit form now has a field for the name of the repo,
so the ugly names that the assistant comes up with for ssh remotes
can be edited as you like. `git remote rename` is a very nice thing.
Changed the preferred content expression for transfer repos to this:
"not (inallgroup=client **and copies=client:2)**". This way, when there's
just one client, files on it will be synced to transfer repos, even
though those repos have no other clients to transfer them to. Presumably,
if a transfer repo is set up, more clients are coming soon, so this avoids
a wait. Particularly useful with removable drives, as the drive will start
being filled as soon as it's added, and can then be brought to a client
elsewhere. The "2" does mean that, once another client is found,
the data on the transfer repo will be dropped, and so if it's brought
to yet another new client, it won't have data for it right away.
I can't see way to generalize this workaround to more than 2 clients;
the transfer repo has to start dropping apparently unwanted content at
some point. Still, this will avoid a potentially very confusing behavior
when getting started.
----
I need to get that dropping of non-preferred content to happen still.
Yesterday, I did some analysis of all the events that can cause previously
preferred content to no longer be preferred, so I know all the places
I have to deal with this.
The one that's giving me some trouble is checking in the transfer scan. If it
checks for content to drop at the same time as content to transfer, it could
end up doing a lot of transfers before dropping anything. It'd be nicer to
first drop as much as it can, before getting more data, so that transfer
remotes stay as small as possible. But the scan is expensive, and it'd also
be nice not to need two passes.
|
