Re: Streamlined application/script development [Re: coding an Application in perl]

On 09/01/2017 04:53 PM, Jean-Louis Martineau wrote:
>> Subcommand 'hotcopy' doesn't accept option '--incremental'
>> Type 'svnadmin help hotcopy' for usage.
> 
> It works for me.

I see, it's a 1.8 thing, science fiction to those of us on Red Hat:
http://subversion.apache.org/docs/release-notes/1.8.html#incremental-hotcopy
Only works for FSFS.

Trivial to add a property for it, though.

Ok, maybe slightly nontrivial; surely the --incremental should be
left off the command if the copy is being created the first time?

Interesting issue:
http://grokbase.com/t/subversion/users/1481xnvkty/svnadmin-pack-vs-hotcopy-incremental

> Also if the backup is not run, do you have some cleanup mechanism to
> delete old snaphost?
...
> If someone run in 'estimate server', it is better to do the snapshot
> in pre-dle-backup.
...
> The lock should be done anyway since a user can run two backup in
> parallel for the same config.
...
>> Maybe a lot of things would be easier if the server would actually
>> remember properties set by early script stages and pass them on
>> to later stages of the application and scripts.
> They could be remember on the client too.

One thing that could make all of that easier, without being very
complicated, would be if the server constructs some unique
identifier (even just a big random number) for one given run
(of amdump or whatever), and passes it in all connections to the
client during that run. That way, scripts could have their
own state storage on the client, but they would be able to know
this invocation of post-dle-backup comes from the same backup
session as that invocation of pre-dle-estimate and should use
the same saved state.

It would then be easy to handle the above issues: a script could
tell in pre-dle-backup if it needs to make a snapshot because
pre-dle-estimate didn't happen (or even happened more than 'max'
minutes ago) for the same backup session.

Amanda::Script::Abstract could even have a method that a script
could use to register something that needs to be cleaned up
later, after the backup, or if the backup didn't run.

Is there any post-*-* event that will get run if the server
was planning a backup but then never ran it? Will the server
still contact the host to run post-dle-backup or even just
post-host-backup in that case? If not, maybe there should be
some aborted-host-backup event that would work that way.

Also, that kind of session identifier could be very useful for
building a permission-granting mechanism that can reliably match
later stages to the exact privileged actions from earlier ones
in the same session.

-Chap