New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

svn.export reports invalid change data (2014.7.x) #21025

Closed
RobertFach opened this Issue Feb 25, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@RobertFach
Contributor

RobertFach commented Feb 25, 2015

Hi,

svn.export reports an issue with an invalid change data when using svn.export. Looking at the code, it shows that the changes structure is not constructed correctly. This might be for historical reasons.

ret['changes'] = name + ' was Exported to ' + target

ret['changes'] = name + ' was Exported to ' + target

should be changed to

ret['changes']['new'] = name
ret['changes']['comment'] = name + ' was Exported to ' + target

version Salt: 2014.7.trunk

I will provide a fix for that.

Another issue is that the change detection itself cannot work correctly. Right now and with the fix, it would always report a change. The general problem behind it is that it looks difficult to detect a change on a directory that is not under version control. Does anybody has an idea on how to do that?

Cheers,

@jfindlay

This comment has been minimized.

Contributor

jfindlay commented Feb 25, 2015

@RobertFach, thanks for reporting. Be sure to submit your pull request against the 2014.7 branch.

I'm not sure what you're asking about when you want the svn state to manage directories that are not managed by svn itself. To me it makes sense that the svn state will limit itself to the functionality provided by svn itself and if there's an edge case that svn can't handle, then the svn state will not be able to improve the situation without in some sense breaking down the meaning of a salt state. Of course, I could be completely wrong because I don't know what your specific case looks like.

@RobertFach

This comment has been minimized.

Contributor

RobertFach commented Feb 26, 2015

@jfindlay Thx for your response. In that special case its about an svn object that gets exported by svn to a file system object without management informations ('.svn' directory). In that case, the state itself is an svn state, but the state itself cannot reason about the exported directoy because the .svn informations are missing. At least, this is how the state change detection works for svn.latest. So my question is, what should be the meaning/semantics of the svn.export state when
a) the directory/file doesn't exists -> it should report a change
b) the directory already exists -> it cannot reason if there was a change, should it always report a change? This would make sense when reasoning from the svn side, because svn would always export..., Also, there's no way to check if the previous export was based on a specific revision...

Correct me if I'm wrong, I also might have missed something.

@jfindlay

This comment has been minimized.

Contributor

jfindlay commented Feb 26, 2015

Those are good questions. It probably won't be difficult to add the extra supervision to the svn state using the file module. On that level you can note the differences between exports, but I don't know of a way to label them with svn revision data.

@jfindlay jfindlay added Feature and removed Bug Medium Severity labels Feb 26, 2015

@RobertFach

This comment has been minimized.

Contributor

RobertFach commented Feb 26, 2015

@jfindlay Please leave the bug label :) Right now, in my opinion its a bug, because it reports invalid change data. However, I don't know yet how to fix that correctly. Do you salt guys @rallytime etc. have a general idea of when a state should report a change? As I sketched it up, sometimes a state might not be able to reasonable detect that a change occured. In principle, a general solution would be to store some meta data to handle that situation correctly or do something else... What are your opinions...? I don't want to fix just the invalid change data issue when I know that there is something more ... :-)

@jfindlay ... I agree, that in principle one could do a svn export and/or additionally a svn checkout/info to get the metadata/revision information. However, where could you store such informations? They don't belong into the exported directory, they would belong just to salt, which uses it to decide about the state change.

@jfindlay

This comment has been minimized.

Contributor

jfindlay commented Feb 26, 2015

The best I can think of is to store that data in a pillar associated with your svn state file. I don't know of any automated way salt can keep track of such metadata automatically.

@stale

This comment has been minimized.

stale bot commented Nov 18, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot added the stale label Nov 18, 2017

@stale stale bot closed this Nov 25, 2017

rallytime added a commit to rallytime/salt that referenced this issue Jul 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment