Closed larshp closed 7 years ago
@nununo try again, latest version
Great to know. Thanks!
I couldn't test it though because when I tried... I bumped into my other problem already reported here #430. I will make a public test case for that one as soon as I can.
closing, this should work
Actually I still have some VARCL differences. I wonder if these are old objects which must be pushed to the repository again in order to be solved. Or should these differences have disappeared altogether?
@nununo try again, latest commit https://github.com/larshp/abapGit/commit/5b12359538158283fa5a45cb16cd2e73fe0d76b2 should fix it, I got some of the flags wrong. Also feel free to submit a pull request
@nununo did this work out for you? I think I'm experiencing the same problem now
Hello, sorry I've been so silent.
Two things happened: I had a go-live and I was told I should not use abapGit anymore during the deployment phase. So it's been over 3 weeks that I was forced to stop using abapGit.
Because of this I haven't been able to do the tests I wanted to.
I'll provide feedback as soon as I can start using it again.
Sorry about this :(
Nuno
no problem, politics?
@nununo Also curious of why stopping, is it "too risky"?
This is a multi-system project and we were using abapGit to sync common code between the systems.
But we were told that each object must have a clearly identified original system. So, we had to stop using abapGit and everything started being done by transport requests so that the original system of the objects remains the same. With abapGit the original system would always be the local system.
Downsides: since we’re still making a lot of changes, we are no longer sure that everything is in sync and now we have to rely on (and wait for) a centralised person who’s responsible for all the transports as we don’t have permissions to do it.
The reason behind this decision does make sense. But I’d have found a more practical way of having both of both worlds. But I’m not the boss…
After the second go-live moment, which is at the end of this month, I’ll start using it again, even if not to actual copy stuff, at least to discover divergences.
Regards, Nuno
On 20 Feb 2017, 05:13 +0000, Lars Hvam notifications@github.com, wrote:
no problem, politics? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Which makes me wonder... would it make sense to add a feature in abapGit to keep the objects' original system? I think this might be helpful! And who knows this way we'd be able to convince the this project (and future ones) to continue using abapGit.
The original system can easily be changed in SE03 after cloning with abapGit.
Alternatively perhaps develop a small utility program to make sure the original system for objects of some spec package is updated.
We could also develop a feature in abapGit, but I am not sure it fits into the git world. But could be a setting at repository level
The original system can easily be changed in SE03 after cloning with abapGit. I know!
Alternatively perhaps develop a small utility program to make sure the original system for objects of some spec package is updated. I’ve done it and it works fine but the person who decides didn’t care! :P
We could also develop a feature in abapGit, but I am not sure it fits into the git world. But could be a setting at repository level I still think it would be a very convenient feature.
Just thoughts: Sorry if out of topic. Reading the above I'm thinking 2 things:
1) I wonder if AG is perceived as a "professional" tool (or more precisely, what needs to be done to move it there) ? I mean corporations usually are very reluctant to installing some 3rd party and opensource stuff to SAP. Unless they heard goods things about it from multiple sources. Imho technically AG is good enough (maybe missing some features like @nununo mentioned). This is more a question of communication (PR) and community size/influence. @larshp is actually doing that with his presentations in SAP events. Maybe something else could be done too.
I guess my clients would not be excited if I ask them to install AG (some online interaction tool) to their system. Although our offline one (see below) which can do ~ similar things (and has some kind of "professional" tint) does not trigger objections.
2) Development vs Deployment
Currently AG is a dev tool. However, there is certainly demand for deployment task. This is not the same. E.g. I'm using AG for out internal dev flows. To deploy (move|update in one direction) our stuff to clients we use use an internal tool which it certainly less elaborate that AG (in particular it does not compare objects) but it have a couple of deployment specific features:
This is what I also lack in AG. Maybe these features can be integrated in AG. Maybe it better be a separate tool which cannot push stuff, but do more checks and comparisons on Pulls.
PR: think main event this week is https://www.dsag.de/seite/dsag-technologietage-2017 where @mrsimpson and 2 others might show abapGit, https://twitter.com/OJaegle/status/828531126171996160
checks if object exist in other packages: I think this is acutally implemented, however it could be better if all the errors/warnings are shown before pull.
Feel free to open separate issues for each feature request :smile:
Nice ! Another presentation :)))
I'll probably make a pull page when I have time (if no one do before me :))
function group top includes
continued from https://github.com/larshp/abapGit/issues/352