Home

Page 1 of 3 123 LastLast
Results 1 to 10 of 23

Thread: Designer + Git

Hybrid View

  1. #1

    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.

  2. #2

    Re: Designer + Git

    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.

  3. #3

    Re: Designer + Git

    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).

  4. #4

    Re: Designer + Git

    Quote Originally Posted by lhaeger View Post
    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.

  5. #5

    Re: Designer + Git

    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.

  6. #6

    Re: Designer + Git

    Quote Originally Posted by ab View Post
    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.

  7. #7

    Re: Designer + Git

    On 01/16/2019 10:34 AM, dgersic wrote:
    >
    > 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.


    Agreed, and also these systems store specific changes. In changing one
    rule from matching "foo" to "bar", I changed, and it tracked, one line of
    code, and I can see that difference to understand exactly what the commit
    message is describing. Binary (non-text) files are not code, and a bunch
    of the project directory is binary **** changing all the time, so using
    anything to version-control that is a non-starter for me. Sure, have a
    backup, whether the project or workspace or a compressed archive, but
    that's not version control as much as disaster recovery. If ever merge or
    commit uses your disaster recovery system, you have too many disasters to
    get work done, and something is probably built incorrectly.

    > 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.


    Yes, but I don't need the cruft; I need my code, just my code, and of
    course that means links among objects (policyset points to policies,
    etc.). I also need the files to have meaningful names somehow Maybe a
    filesystem directory structure which matches, to some extent, the IDM
    directory structure (not the whole directory, just the IDM bits like we
    have in the Outline view).

    > 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.


    Yes, and completely useless for version control, so not done. When you
    commit a change, I do not want to lose (or at least close) all of my work
    just to view it.

    > 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.


    I think this is missing the point. If we want to backup and restore
    projects, we can do that now, and that's been possible since Designer
    first came out. We need standard version control functionality with some
    focus on IDM, and in my mind that means objects in the directory are
    represented in files, structured in directories like their containers,
    linked via XML metadata if needed, and able to be checked in with only
    differences tracked, as is normal for every other bit of code on the planet.

    > 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.


    Doing this would also naturally lead to fixes on the code promotion
    problem. Have a branch for prod, one for QA, one for test, and a release
    branch. Develop feature branches, merge into test, when done move into
    release. When done with that, merge up into QA, then later into Prod.
    Clean movement of code up the line, and that could all still be in
    Designer (skipping the #4 idea), or headless Designer could make the #4
    part happen.

    Yes, it's a bit of work, but without any feedback from anybody
    authoritative, I can only presume other priorities take the time to even
    start investigating if it really is hard, or if, with the right people,
    it's a week's work.

    Considering the Compare/Deploy functionality already knows how to work
    with XML and specific objects, I think this is easier than it may seem,
    however simplistic that view I may have. If the Compare/Deploy
    functionality was used to now Compare/Deploy with the filesystem, and the
    filesystem was basically the Outline view (plus UserApp cruft), that would
    be pretty good. Build in automatic committing, pushing, and pulling, and
    you're done.

    --
    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.

  8. #8

    Re: Designer + Git

    Quote Originally Posted by ab View Post
    On 01/16/2019 10:34 AM, dgersic wrote:
    >
    > 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.


    Agreed, and also these systems store specific changes. In changing one
    rule from matching "foo" to "bar", I changed, and it tracked, one line of
    code, and I can see that difference to understand exactly what the commit
    message is describing. Binary (non-text) files are not code, and a bunch
    of the project directory is binary **** changing all the time, so using
    anything to version-control that is a non-starter for me. Sure, have a
    backup, whether the project or workspace or a compressed archive, but
    that's not version control as much as disaster recovery. If ever merge or
    commit uses your disaster recovery system, you have too many disasters to
    get work done, and something is probably built incorrectly.

    > 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.


    Yes, but I don't need the cruft; I need my code, just my code, and of
    course that means links among objects (policyset points to policies,
    etc.). I also need the files to have meaningful names somehow Maybe a
    filesystem directory structure which matches, to some extent, the IDM
    directory structure (not the whole directory, just the IDM bits like we
    have in the Outline view).

    > 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.


    Yes, and completely useless for version control, so not done. When you
    commit a change, I do not want to lose (or at least close) all of my work
    just to view it.

    > 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.


    I think this is missing the point. If we want to backup and restore
    projects, we can do that now, and that's been possible since Designer
    first came out. We need standard version control functionality with some
    focus on IDM, and in my mind that means objects in the directory are
    represented in files, structured in directories like their containers,
    linked via XML metadata if needed, and able to be checked in with only
    differences tracked, as is normal for every other bit of code on the planet.

    > 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.


    Doing this would also naturally lead to fixes on the code promotion
    problem. Have a branch for prod, one for QA, one for test, and a release
    branch. Develop feature branches, merge into test, when done move into
    release. When done with that, merge up into QA, then later into Prod.
    Clean movement of code up the line, and that could all still be in
    Designer (skipping the #4 idea), or headless Designer could make the #4
    part happen.

    Yes, it's a bit of work, but without any feedback from anybody
    authoritative, I can only presume other priorities take the time to even
    start investigating if it really is hard, or if, with the right people,
    it's a week's work.

    Considering the Compare/Deploy functionality already knows how to work
    with XML and specific objects, I think this is easier than it may seem,
    however simplistic that view I may have. If the Compare/Deploy
    functionality was used to now Compare/Deploy with the filesystem, and the
    filesystem was basically the Outline view (plus UserApp cruft), that would
    be pretty good. Build in automatic committing, pushing, and pulling, and
    you're done.

    --
    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.
    I completely agree, but while you're asking for all of that, you might as well request a unicorn to go with it. Unless you have some magic way to get prioritization on building all of this, you're kinda stuck with "no, it doesn't do that". I'm thinking that something might be better than nothing, at least until unicorns start getting delivered.

  9. #9

    Re: Designer + Git

    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...

  10. #10

    Re: Designer + Git

    ab wrote:

    > 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.


    Isn't that what we have in the project folder already?

    --
    http://www.is4it.de/en/solution/iden...ss-management/

    (If you find this post helpful, please click on the star below.)

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •