Designer Git

We've batted this around before, but it doesn't seem like git support in Designer is going to happen any time soon. What would it actually take to do this without official support?

I've worked with several revision control systems. In the end, what they care about most is files. We have files, they're stored under the workspace directory.

Would it be sufficient to create a git repository, and shove the workspace in to it so that it can be managed using git's tools? Sure, it wouldn't be as pretty and nice as doing this in Designer itself, but would it work? If not, why not?

I think the basics of it might work.

Tags:

Parents
  • On 2019-01-16 15:46, dgersic wrote:
    >
    > We've batted this around before, but it doesn't seem like git support in
    > Designer is going to happen any time soon. What would it actually take
    > to do this without official support?
    >
    > I've worked with several revision control systems. In the end, what they
    > care about most is files. We have files, they're stored under the
    > workspace directory.
    >
    > Would it be sufficient to create a git repository, and shove the
    > workspace in to it so that it can be managed using git's tools? Sure, it
    > wouldn't be as pretty and nice as doing this in Designer itself, but
    > would it work? If not, why not?
    >
    > I think the basics of it might work.
    >
    >

    Hello
    We are using Bitbucket (which is using git) manually outside of Designer
    and have done so for almost a year.

    So far we haven't had any issues I'm aware of.



    --
    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.
  • alekz wrote:

    > We are using Bitbucket (which is using git) manually outside of Designer and
    > have done so for almost a year.
    >
    > So far we haven't had any issues I'm aware of.


    I would expect this to work just fine as long as you always commit/update the
    whole project.

    But as soon as you commit - say - an newly added driver only, Designer applies
    some logic to find all references to that driver (e.g. in driverset, package
    catalog etc.) and commits those as well. I think Designer will also not only
    look at complete files but must have to work on it's contents, too. E.g. you
    add to new drivers to a project, both using the same package. Now when you only
    commit one of those drivers, the package installed on both holds a reference to
    both drivers but would only have to be committed in a version that references
    only one of them (until you also commit the second driver). This mess should
    have been avoided in the first place by choosing an appropriate file model on
    disk (if that was possible at all).

    At least that's how I imagine the underlying problem of adding git support (or
    even only bringing the SVN client plugin up to date).
  • lhaeger;2493758 wrote:
    alekz wrote:

    > We are using Bitbucket (which is using git) manually outside of Designer and
    > have done so for almost a year.
    >
    > So far we haven't had any issues I'm aware of.


    I would expect this to work just fine as long as you always commit/update the
    whole project.

    But as soon as you commit - say - an newly added driver only, Designer applies
    some logic to find all references to that driver (e.g. in driverset, package
    catalog etc.) and commits those as well. I think Designer will also not only
    look at complete files but must have to work on it's contents, too. E.g. you
    add to new drivers to a project, both using the same package. Now when you only
    commit one of those drivers, the package installed on both holds a reference to
    both drivers but would only have to be committed in a version that references
    only one of them (until you also commit the second driver). This mess should
    have been avoided in the first place by choosing an appropriate file model on
    disk (if that was possible at all).

    At least that's how I imagine the underlying problem of adding git support (or
    even only bringing the SVN client plugin up to date).


    Yeah, I was assuming you'd have to commit the entire thing. It wouldn't make sense to only commit part of the project, because of the various files that reference other files.

    Agreed, the file model on disk is the difficult part here. Without knowing what they all are, and how they work, reverse engineering it well enough to make something like a partial commit work correctly is probably not going to happen.
  • While we've all been after this for a while, I have a hard time talking
    myself into believing there is improvement if the whole project, or even
    workspace, is tossed into Git. This is nothing better than any other
    filesystem backup mechanism, except that maybe it's easier for us to
    control. Any backup would probably need to have Designer closed for
    safety, and any restore would definitely need Designer closed to read the
    new workspace data. There is no way to do meaningful diffs, or merges, or
    anything like that.

    As always, I think Designer needs a couple things:

    1. The ability to export objects to the filesystem. Driver object get a
    file, each policy object gets a file, some files work for the UserApp
    mess, and so on.

    2. Hopefully obvious, Designer needs to be able to import from that same
    place.

    3. Ideally Designer learns how to interact with Git, and manages commits
    within there directly, but if not at least using Git to commit changes,
    view differences, and the with #1 above would be possible.

    4. Pipe dream: make it possible for deployment to happen on the IDM box,
    maybe with headless Designer, so outside access could be blocked.

    IDM is an interesting tool from a source code point of view because the
    running code is ONLY ever in eDirectory, which is completely different
    from Designer in how it stores files, what it does, etc. With other
    software projects, IDM included (internally, not as a product we use),
    development happens in a tool like Eclipse (Designer for us) and a
    finished product is built on a server, pulling those changes in from
    something like Git (or older wanna-be Git systems). The IDE does not push
    the latest code into some server and then run it, yet that is how Designer
    works with IDM. It has its copy, the IDM engine has its copy, and
    sometimes we keep other black-box copies in SVN.

    For the record, it is nice being able to make changes lives without
    restarting eDirectory, or rebuilding drivers, or accessing servers
    directly, but because we ONLY have this model, we lose the benefits of the
    other model, which is where everybody else works with plain old text
    files, representing logical code things (Java files, properties files,
    resource files) and we have corresponding logical code things (driver
    objects, policy objects, mapping table objects), but no corresponding
    functionality.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • ab;2493764 wrote:
    While we've all been after this for a while, I have a hard time talking
    myself into believing there is improvement if the whole project, or even
    workspace, is tossed into Git. This is nothing better than any other
    filesystem backup mechanism, except that maybe it's easier for us to
    control. Any backup would probably need to have Designer closed for
    safety, and any restore would definitely need Designer closed to read the
    new workspace data. There is no way to do meaningful diffs, or merges, or
    anything like that.

    As always, I think Designer needs a couple things:

    1. The ability to export objects to the filesystem. Driver object get a
    file, each policy object gets a file, some files work for the UserApp
    mess, and so on.

    2. Hopefully obvious, Designer needs to be able to import from that same
    place.

    3. Ideally Designer learns how to interact with Git, and manages commits
    within there directly, but if not at least using Git to commit changes,
    view differences, and the with #1 above would be possible.

    4. Pipe dream: make it possible for deployment to happen on the IDM box,
    maybe with headless Designer, so outside access could be blocked.

    IDM is an interesting tool from a source code point of view because the
    running code is ONLY ever in eDirectory, which is completely different
    from Designer in how it stores files, what it does, etc. With other
    software projects, IDM included (internally, not as a product we use),
    development happens in a tool like Eclipse (Designer for us) and a
    finished product is built on a server, pulling those changes in from
    something like Git (or older wanna-be Git systems). The IDE does not push
    the latest code into some server and then run it, yet that is how Designer
    works with IDM. It has its copy, the IDM engine has its copy, and
    sometimes we keep other black-box copies in SVN.

    For the record, it is nice being able to make changes lives without
    restarting eDirectory, or rebuilding drivers, or accessing servers
    directly, but because we ONLY have this model, we lose the benefits of the
    other model, which is where everybody else works with plain old text
    files, representing logical code things (Java files, properties files,
    resource files) and we have corresponding logical code things (driver
    objects, policy objects, mapping table objects), but no corresponding
    functionality.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.


    The chief benefit I see to using git (or SVN or insert your preferred system here) is the storing comments along with the changes. So if I need to know when Foo changed from doing Bar to doing Baz, I can have a reasonable look at what that change entailed, what other changes went with it, and what has changed since. I can't easily revert that change without addressing the side effects.

    1. Everything is already files in the file system. We call them a Designer "project". But you can wander around the undocumented and fairly opaque directory structure looking at the files. It's all there somewhere.

    2. Designer can export the whole mess to an archive. And it can import that archive. So to some degree, this is also already done.

    As far as I can tell, #1 and #2 together indicate that copying the relevant stuff out of a project directory and in to another project directory is almost kinda all Designer actually needs. I haven't looked in to the link from the workspace to the individual projects within. That may be a hurdle, to get Designer to see a newly (git imported) project.

    3. Yeah, this is what we want. It's been on the list of things to do, someday, for about 10 years now. At this point, I don't expect to see it happen, and I'm kinda tired of waiting for it. It took d*mn near forever to get SVN support, and even longer to get it to the point where it actually worked, and mostly didn't suck. They've been hemming and hawing about git support ever since.

    4. Would be cool. Would be interesting. Depends on #3. At this point, I expect the heat death of the universe to happen first.
  • ab wrote:

    > IDM is an interesting tool from a source code point of view because the
    > running code is ONLY ever in eDirectory, which is completely different
    > from Designer in how it stores files, what it does, etc. With other
    > software projects, IDM included (internally, not as a product we use),
    > development happens in a tool like Eclipse (Designer for us) and a
    > finished product is built on a server, pulling those changes in from
    > something like Git (or older wanna-be Git systems). The IDE does not push
    > the latest code into some server and then run it, yet that is how Designer
    > works with IDM. It has its copy, the IDM engine has its copy, and
    > sometimes we keep other black-box copies in SVN.


    That's an interesting approach. The production IDM servers could always pull
    the "master" branch and build/deploy/run it as current state of the whole
    system. Individual driver developments or bug fixes etc would always occur in
    their own branches and could be pulled by dev and test server. Once an item has
    been developed for testing, it's development branch could be merged into a "QA"
    branch running on a test server, and once approved for production, merged into
    master.

    I'd really like to do this with git and not svn because of the MUCH better
    branching/merging/pull requests capabilities etc. though...
Reply
  • ab wrote:

    > IDM is an interesting tool from a source code point of view because the
    > running code is ONLY ever in eDirectory, which is completely different
    > from Designer in how it stores files, what it does, etc. With other
    > software projects, IDM included (internally, not as a product we use),
    > development happens in a tool like Eclipse (Designer for us) and a
    > finished product is built on a server, pulling those changes in from
    > something like Git (or older wanna-be Git systems). The IDE does not push
    > the latest code into some server and then run it, yet that is how Designer
    > works with IDM. It has its copy, the IDM engine has its copy, and
    > sometimes we keep other black-box copies in SVN.


    That's an interesting approach. The production IDM servers could always pull
    the "master" branch and build/deploy/run it as current state of the whole
    system. Individual driver developments or bug fixes etc would always occur in
    their own branches and could be pulled by dev and test server. Once an item has
    been developed for testing, it's development branch could be merged into a "QA"
    branch running on a test server, and once approved for production, merged into
    master.

    I'd really like to do this with git and not svn because of the MUCH better
    branching/merging/pull requests capabilities etc. though...
Children
No Data