GIT for Microsoft Access projects

Hello,

I'm Paul Hacker here in Tyler Texas.

We are looking for a software control system to keep track of our changes in software.

My question is, will GIT work with MS access forms, queries, tables, modules, etc?

Thanks for any help.

Paul (yes my last name is Hacker!!)

On Mon, 8 Jun 2015 9:45:17 -0500
[off-list ref] wrote:

[...]

My question is, will GIT work with MS access forms, queries, tables,
modules, etc?

[...]

Git works with files.  So in principle it will work with *files*
containing your MS access stuff.

But Git will consider and treat those files as opaque blobs of data.
That is, you will get no "fancy diffing" like asking Git to graphically
(or otherwise) show you what exact changes have been made to a
particular form or query between versions X and Y of a given MS access
document -- all it will be able to show you is commit messages
describing those changes.

So... If you're fine with this setting, Git will work for you,
but if not, it won't.

One last note: are you really sure you want an SCM/VCS tool to manage
your files and not a document management system (DMS) instead?
I mean stuff like Alfresco (free software by the way) and the like.

-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Konstantin Khomoutov
Sent: June 8, 2015 12:15 PM
To: hackerp@suddenlink.net
Cc: git@vger.kernel.org
Subject: Re: GIT for Microsoft Access projects

On Mon, 8 Jun 2015 9:45:17 -0500
[off-list ref] wrote:

[...]

quoted

My question is, will GIT work with MS access forms, queries, tables,
modules, etc?

[...]

Git works with files.  So in principle it will work with *files*
containing your MS access stuff.

But Git will consider and treat those files as opaque blobs of data.
That is, you will get no "fancy diffing" like asking Git to graphically
(or otherwise) show you what exact changes have been made to a
particular form or query between versions X and Y of a given MS access
document -- all it will be able to show you is commit messages
describing those changes.

So... If you're fine with this setting, Git will work for you,
but if not, it won't.

One last note: are you really sure you want an SCM/VCS tool to manage
your files and not a document management system (DMS) instead?
I mean stuff like Alfresco (free software by the way) and the like.

Consider also what you are specifically managing in MS Access. Are you
looking for management of configuration data, like settings, properties, and
such, or is this transactional or user-related. If managing
environment-specific content, it may be worth storing raw SQL INSERT
statements, with appropriate variable references, or export to XML/CSV, and
having those in git so that the purpose for configuration-like data can be
explained and diff'ed.

On 06/08/2015 09:44 PM, Konstantin Khomoutov wrote:

On Mon, 8 Jun 2015 9:45:17 -0500
[off-list ref] wrote:

[...]

quoted

My question is, will GIT work with MS access forms, queries, tables,
modules, etc?

[...]

Git works with files.  So in principle it will work with *files*
containing your MS access stuff.

But Git will consider and treat those files as opaque blobs of data.
That is, you will get no "fancy diffing" like asking Git to graphically

More importantly, you won't get any *merging*, which means you need to
be careful about two developers making changes to the same file.

This is the only situation where locking (a feature that is inherently
at odds with the idea of a *distributed* VCS) is useful.

(or otherwise) show you what exact changes have been made to a
particular form or query between versions X and Y of a given MS access
document -- all it will be able to show you is commit messages
describing those changes.

So... If you're fine with this setting, Git will work for you,
but if not, it won't.

One last note: are you really sure you want an SCM/VCS tool to manage
your files and not a document management system (DMS) instead?
I mean stuff like Alfresco (free software by the way) and the like.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Just because Git allows distributed workflows, doesn't mean we
should only focus on being distributed IMHO.

The question for content not being mergable easily pops up all
the time. (Game/Graphics designers, documents, all this binary
stuff, where there is no good merge driver).

I could imagine a "git lock" command which looks like this:

    git config lock.centralServer origin
    git config lock.defaultBranch master

    git lock add [branch]  [--] <path/to/file>
    git lock remove [branch] [--] <path/to/file>
    git lock ls [<branch>]

And the way this is implemented is roughly (unoptimized, just showing
how you would achieve this with todays command set):

    git fetch --depth=1 $(git config --get lock.centralServer) refs/locks/$(git config --get lock.defaultBranch)
    git checkout refs/locks/$(git config --get lock.centralServer)/$(git config --get lock.defaultBranch)
    switch(option) {
    case add:
        if exist <path/to/file>
            return -1
        else
            echo $(git config --get user.name) $(date) > <path/to/file>
            git add <path/to/file> && git commit "add new lock"
        fi
    case remove:
        if exist <path/to/file>
            # todo: check if the same user locked it before
            rm  <path/to/file>
        else
            return -1
        fi
    case ls:
        ls -R .
    }
    git push $(git config --get lock.centralServer) refs/locks/$(git config --get lock.defaultBranch)
    git <restore working tree, branch>

That said you could just manipulate the git objects directly, no need
to check out to the working dir.

The server would only need to allow pushes to a refs/locks directory and be done.
the client side would need to have a plumbing command, so you could easily integrate
a git locking to your application if you don't want to provide a merge driver.

Thanks,
Stefan

Thanks folks, I am digesting all you have said.

Now the command line I can do (I'm a programmer) but the secretary here I doubt.

So is there at GUI interface for this? Does it work on Windows systems?

Thanks,

Paul
---- Stefan Beller [off-list ref] wrote: 

Just because Git allows distributed workflows, doesn't mean we
should only focus on being distributed IMHO.

The question for content not being mergable easily pops up all
the time. (Game/Graphics designers, documents, all this binary
stuff, where there is no good merge driver).

I could imagine a "git lock" command which looks like this:

    git config lock.centralServer origin
    git config lock.defaultBranch master

    git lock add [branch]  [--] <path/to/file>
    git lock remove [branch] [--] <path/to/file>
    git lock ls [<branch>]

And the way this is implemented is roughly (unoptimized, just showing
how you would achieve this with todays command set):

    git fetch --depth=1 $(git config --get lock.centralServer) refs/locks/$(git config --get lock.defaultBranch)
    git checkout refs/locks/$(git config --get lock.centralServer)/$(git config --get lock.defaultBranch)
    switch(option) {
    case add:
        if exist <path/to/file>
            return -1
        else
            echo $(git config --get user.name) $(date) > <path/to/file>
            git add <path/to/file> && git commit "add new lock"
        fi
    case remove:
        if exist <path/to/file>
            # todo: check if the same user locked it before
            rm  <path/to/file>
        else
            return -1
        fi
    case ls:
        ls -R .
    }
    git push $(git config --get lock.centralServer) refs/locks/$(git config --get lock.defaultBranch)
    git <restore working tree, branch>

That said you could just manipulate the git objects directly, no need
to check out to the working dir.

The server would only need to allow pushes to a refs/locks directory and be done.
the client side would need to have a plumbing command, so you could easily integrate
a git locking to your application if you don't want to provide a merge driver.

Thanks,
Stefan

On Tue, 9 Jun 2015 13:21:44 -0500
[off-list ref] wrote:

Thanks folks, I am digesting all you have said.

Now the command line I can do (I'm a programmer) but the secretary
here I doubt.

So is there at GUI interface for this? Does it work on Windows
systems?

That's why I asked whether the thing you do really want is a document
management system, not a version control system.

Yes, Git works on Windows thanks to folks behind the Git for Windows
project (often and errorneously called "msysGit" in the internets)
and yes there do exist mature Windows GUI front-ends to it, with
TortoiseGit and Git Extensions being supposedly the most visible picks.

But there's such thing as an irreducible complexity: while these tools
strive to be user-friendly, and TortoiseGit even tries to make you
think you're using Subversion rather than Git, they won't hide all the
underlying complexity of a DVCS tool, which Git is, from the user.

So... I bet for your random user, it would be much easier to switch to
the browser window and upload another version of their document there,
with a short note describing what they do and why.  This is how a
typical DMS works.  You won't get all that awesomness Git gives you to
fiddle with your source code files but in return you'll get a system
which requires next to zero training for any layman to use it.

Please rememeber about [1].  Many of the statements that post does are
outdated but its essense remains to be true when it comes to handing
off Git to users not possessing ninja-level computer skills.
I especially recommend to think through this particular passage:

| They often struggle to use version control at all; are you now going
| to teach them the difference between “pull” and “update”, between
| “commit” and “push”? Look me in the eyes and say that with a straight
| face.

I also wonder how do you intend to explain them why they can't push
because someone else had just did that, and what to do about this, and
why.  (And whose version should win, in the end, as the files you
intend to work with are not subject for merging in the usual sense of
this word -- when it comes to plain text files.)

1. http://blog.red-bean.com/sussman/?p=79

On Tue, Jun 9, 2015 at 11:21 AM,  [off-list ref] wrote:

Thanks folks, I am digesting all you have said.

I did not intend to answer your original question, but to start a
discussion on the
feasibility of a dedicated "git lock" command.

There are lots of things which are checked in alongside the code
(The code is which is why you want to use Git in the first place),
such as Graphics, CAD, design documents (maybe in binary format such as ODF,
MS Excel).

All I did was proposing a new command and laying out its behavior.
By being careful at what to use as the porcelain command line and what to use
as a stable plumbing command, other programs could rely on that.
(Some proprietary CAD tools such as Altium have a subversion
integration [1], maybe Git wants to offer an easy interface to allow
for Git integration as easily?)

Now the command line I can do (I'm a programmer) but the secretary here I doubt.

So is there at GUI interface for this? Does it work on Windows systems?

As all I was saying is dreaming out new concepts, there is currently no code.

Thanks,

Paul

[1] http://techdocs.altium.com/display/ADOH/Version+Control+and+Altium+Designer

On Tue, Jun 09, 2015 at 10:19:43AM -0700, Stefan Beller wrote:

Just because Git allows distributed workflows, doesn't mean we
should only focus on being distributed IMHO.

The question for content not being mergable easily pops up all
the time. (Game/Graphics designers, documents, all this binary
stuff, where there is no good merge driver).

I could imagine a "git lock" command which looks like this:

You do know that gitolite has locking functionality?

-- 
Fredrik Gustafsson

phone: +46 733-608274
e-mail: iveqy@iveqy.com
website: http://www.iveqy.com

On Wed, Jun 10, 2015 at 12:47 AM, Fredrik Gustafsson [off-list ref] wrote:

On Tue, Jun 09, 2015 at 10:19:43AM -0700, Stefan Beller wrote:

quoted

Just because Git allows distributed workflows, doesn't mean we
should only focus on being distributed IMHO.

The question for content not being mergable easily pops up all
the time. (Game/Graphics designers, documents, all this binary
stuff, where there is no good merge driver).

I could imagine a "git lock" command which looks like this:

You do know that gitolite has locking functionality?

Yes, and it's cooking its own thing, it's not upstream (in git core I mean)

Locking is useful not just when using gitolite, but any hosting
solution I believe.