3.5.5 Versions in a multi-user repository
The MetaEdit+ multi-user server already integrates the work of
multiple users, so versioning in a multi-user environment is as easy as with a
single user: no need to fetch others’ changes and deal with diff, merge
and conflicts.
Following VCS best practices, we will assume that all
users share the same remote VCS, but each user has his own local VCS working
directory.
Initial setup is mostly as described in Section
3.5.2, with a slight change for users
after the first, described in ‘
Subsequent users’
below.
First user
One user will create the remote VCS repository, set the
VCS
Settings |
Paths..., run
Extra VCS Commands |
Init, and perform the first
Save Version.
Where possible, the settings in
Paths should be such that they are valid
for all users of this db.
• dbName and dbBaseDir can be valid for all in
normal cases. dbBaseDir will need changing from the default
'.', most commonly to a UNC,
e.g.
$dbBaseDir =
'\\MESERVER\meshare'
• metaeditExe may require changes, e.g. if some
users are on 32-bit Windows with Program Files and others on 64-bit Windows with
Program Files (x86).
• gitBaseDir and svnBaseDir are generally easy to
keep consistent with a common policy.
• gitBaseURL or svnBaseURL can generally be the
same. The exception is if the URL contains a particular user’s name for
authentication (e.g. otherUser@ before the server name). In some cases that can
be left off (e.g. BitBucket), being provided by information elsewhere (e.g. Git
wincred); in other cases it will need to be overridden by each user in their
.vcsPaths, as
detailed below.
| If
all users share the same gitBaseURL account (e.g. ourOrg@ on BitBucket), that
can of course be valid for all. Then, if each user has their own Git user.email
and user.name, these will show up for that user's versions in BitBucket: the
user versions to the local Git as that user, and the shared organization
credentials are used when pushing that version (with its existing user details)
to
BitBucket. |
Subsequent users
Subsequent users need to check and if necessary override
Paths... settings, and do
InitClone instead
of
Init. Full details are provided below.
Each subsequent user can login to the multi-user
repository and check that settings in
VCS Settings |
Paths... are appropriate for their machine and
user. They cannot sensibly change the settings there, as that would affect all
users. However, they can override settings there by creating a
.vcsPaths
file: see Section
3.5.6.
With the VCS Paths correct, the user can run Extra VCS
Commands | InitClone to set up their local VCS working directory. (As
the MetaEdit+ repository already exists on the server, this will not overwrite
it.)
The user can then work as normal, doing
Save
Version when appropriate.
Synchronizing generated output with versions
If you need to generate code at exactly the same state as the
version, run the generator after Save Version. This ensures that all
other users’ changes included in the version are also included in the
generated code.
The possible differences between the situations before and
after
Save Version are the changes in other users’ transactions
committed after your transaction started and before your Save Version. To make
sure you take those changes into account before making an important version, you
can
Commit your transaction first, generate and test, then
Save
Version and generate again.
Ensuring all changes are documented for a release
When making a release or other particularly major version, you
may want to ensure that not only your changes but also all other users’
changes are versioned and documented in version comments, with no changes since.
To do this, ask the other users to do a
Save Version and logout. You can
then do
Save Version with
Save as Release
selected. Versions that are releases are highlighted in bold in the Changes
& Versions
Tool.