I wonder.. I know Dropbox files are constantly synchronized,
but if one person (an administrator) sets all files in read-only..
would that prevent any deleting/editing by anyone else?
And for versioning, as you suggested (if I got you right?),
until some form of package control system could be thought-up/setup
perhaps having entire workgroup versions (1.2, 1.4, ...) ? (1 every
month?)
With each new version essentially being almost an exact copy of the
previous,
but with individual updates that happened since the last workgroup
version, plus new items.
So if one were to connect to V1.3 at the start of a prod, (or download
it to a local server)
he could either stick with that version, and/or test-out new ones as
they come out,
and could always fall back to previous ones.
This while perhaps having a "Nightly Build Workgroup", where all updates
happen live.
(for daredevils or curious cats)
Also, I remember having used a free FTP drive mapping thingy a while back..
could that solve many (if not any?) permission issues?
For what would be on there,
I would think of perhaps putting up a list of good item candidates, (on
SI-Community?)
were people could vote or post suggestions of what they would find useful..
And I think the result would feel (& be) like a live connection to
what everyone in the community finds useful :-),
while highly doubting that anything "useless" (or for too specific
contexts)
would find it's way in there.
Any suggestions?
Cheers!
On 23/01/2013 1:27 PM, Andy Jones wrote:
Fantastic thread. I could actually see something like Dropbox working
as an always up to date thing, but only if there's a way for each tool
owner to provide read-only access into some sort of central "hub." So
you'd see all the tools together, but each would be managed by one
person. And for stability, I'd assume people would make copies of
that repo if they're worried about stuff changing.
It might be too complex for it to actually happen, but more along the
lines of a package system, I would recommend that we first figure out
how to put all these tools into a code repository, not unlike how most
studios manage their tools. Something like git would probably be
ideal (though I know people sometimes get scared off by the
complexity). The great thing about working this way is that if people
make improvements to the tools, there's a way to push the improvements
back up to the main code repository in a controlled way. It's really
not any different from other open source software.
Something I do think is missing, though, is a way of managing plugins
that fills the gap between workgroups and "loose" scripts. I think
Addons were really meant to be this, but apart from installing and
uninstalling them, they can be somewhat difficult to manage. It would
be great if we had a really slick way to create a workgroup consisting
of only our deployed addons, which would let us perform upgrades and
such very easily. For example, inside the workgroup, you could have
some metadata that lists locations where addons can be pulled from
(like how rpm databases work), and would let you search for things and
install/uninstall/upgrade them. So there would be two parts -- source
checkin/checkout, and package installation/management.
Another thought is that it would be wise to separate tools that are
instantaneous (like gui scripts, etc) and tools that create
dependencies, and which need to be deployed elsewhere once the tool is
used. The former always has fewer strings attached, so it's easier to
carry it around like a "bag of tricks."
On Fri, Jan 18, 2013 at 9:35 PM, Jason S <[email protected]
<mailto:[email protected]>> wrote:
Jason S wrote:
I there are any conflicts, could it make any permanent changes to
which just disconnecting from the workgroup wouln't resolve? Or
can just connecting to a workgroup possibly execute code?
By the way, what happens when connecting to a workgoup with
things that are already locally installed?
In the same vein, what happens when installing an addon with
various extensions which includes things that are already installed?
are those things overwritten? or display popups?
So many questions sorry :)
Found some answers to my many question from the good ol' manual :)
*Resolving Plug-in Conflicts*
Plug-in conflicts occur when Softimage finds multiple versions of
the same self-installing plug-in.
Softimage can resolve a plug-in conflict in either of two ways:
• Versioning:
Softimage loads the most recent version of the plug-in.
• Origin Ordering:
Softimage loads the plug-in from the location with the highest
precedence.
By default, Softimage tries to load the most recent version of a
self-installing plug-in.
For example, if your User location contains version 1.2 of a plug-in,
and a workgroup contains 1.3, then Softimage loads version 1.3.
If all copies of a plug-in are the same version, then Softimage
uses origin ordering to resolve the conflict.
You can change how Softimage resolves conflicts by setting the
Plug-in Manager preference named Conflict Resolution.
For non-self-installing plug-ins and other customizations (Addons),
Softimage uses origin ordering and loads the first copy of the
plug-in that it finds in the following order:
1. Custom locations.
Custom locations are the paths specified by the XSI_PLUGINS
environment variable.
2. User location.
Add-ons in the User location are loaded after any other plug-ins
found in the User location (for example, plug-ins in
%XSI_USERHOME%\Application\Plugins are loaded before plug-ins
in%XSI_USERHOME%\Addons).
3. Workgroups.
Softimage searches workgroups in the order they are listed in the
Plug-in Manager
(so the first workgroup in the list takes precedence).
Add-ons in a workgroup are loaded after any other plug-ins found
in the workgroup
(for example, plug-ins in MyWorkgroup\Application\Plugins are
loaded before plug-ins in MyWorkgroup\Addons).
4. Factory location.
This is the directory in which Softimage is installed.
