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;2493743 wrote:
    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.


    That's interesting, and encouraging. Any best practices to share? Have you explored using .gitignore to keep it from maintaining any of the other stuff that Designer caches that isn't helpful?
Reply
  • alekz;2493743 wrote:
    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.


    That's interesting, and encouraging. Any best practices to share? Have you explored using .gitignore to keep it from maintaining any of the other stuff that Designer caches that isn't helpful?
Children
  • On 2019-01-16 17:56, dgersic wrote:
    > That's interesting, and encouraging. Any best practices to share? Have
    > you explored using .gitignore to keep it from maintaining any of the
    > other stuff that Designer caches that isn't helpful?

    We use it for a project where the packages are built.

    Have to check if we are using .gitignore.

    When you are done with developing you do a git add -A, then a git commit
    -a -m "message" and finally a git push

    --
    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.
  • I also work with git. I mainly do drivers and you can export them nicely. As far as I know the same doesn't apply to workflows or other UserApp entities.

    The main benefit I see is being able to diff different commits and see what changed, when and who's to blame. I guess that the same could be achieved without git, just by using diff exported_driver_v1.xml exported_driver_v2.xml, but then you loose commit messages.
  • Hi!

    I'm interested in how you work with drivers and export them.

    I'm used to work with code like C or Java where everything is stored in a sensible file structure and having a hard time figuring out how to work effectively in the Designer.
    I really miss the branch/merge and diff that gives me a lot more freedom to elaborate during development.

    When you say you're working with drivers, do you implement each driver in a separate project?
    And then export them and import them in a system project for deployment to IDM-server?

    If so, it sounds somewhat like something I've been considering.

    Can you even branch and merge using your working pattern? That would be really nice.
    How do you perfrom (unit)testing on the individual drivers?
    Or do you only test them after delivery (export/import)?

    BR
    /Thomas
  • liasson;2498420 wrote:
    Hi!

    I'm interested in how you work with drivers and export them.

    I'm used to work with code like C or Java where everything is stored in a sensible file structure and having a hard time figuring out how to work effectively in the Designer.
    I really miss the branch/merge and diff that gives me a lot more freedom to elaborate during development.

    When you say you're working with drivers, do you implement each driver in a separate project?
    And then export them and import them in a system project for deployment to IDM-server?

    If so, it sounds somewhat like something I've been considering.

    Can you even branch and merge using your working pattern? That would be really nice.
    How do you perfrom (unit)testing on the individual drivers?
    Or do you only test them after delivery (export/import)?

    BR
    /Thomas


    Working with Designer SVN, I treated the project as a single monolythic thing that could be checked out / checked in. I arranged my work to only change a related collection of things at a time, and described what changed in the checkin comments.

    I don't especially like that, but it worked. I think we need to envision how Designer git would work, in order to move this idea forward. How would you use it, if you had it? What functionality would you use? What would you ignore?
  • Maybe I was a little vague.
    I was mainly interested in msira's way of working.

    BR
    /Thomas