On 2009-09-02 12:05:19 -0500, Jon Nelson wrote:

...

there were plenty changes in osc svn, so it is time for a new release. However, there might be unwanted incompatibilities, so I prepared first a candidate in openSUSE:Tools:Unstable

I'd like to see the

File `somefile' is not in package meta. Would you like skip/remove/edit file lists/commit/abort? (s/r/e/c/A)

part removed. I personally find it very annoying. Also, the question itself doesn't really make sense.

If you want to disable this check add "check_filelist = 0" to the "[general]" section in your ~/.oscrc. IMHO it would be better if it only checks for files which are referenced in the spec file (SourceX, PatchX etc) instead of checking all files in the working copy. Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wed, Sep 02, 2009 at 12:22:17 -0500, Jon Nelson wrote:

On Wed, Sep 2, 2009 at 12:14 PM, Marcus Hüwe wrote:

...

On 2009-09-02 12:05:19 -0500, Jon Nelson wrote:

...

...

there were plenty changes in osc svn, so it is time for a new release. However, there might be unwanted incompatibilities, so I prepared first a candidate in openSUSE:Tools:Unstable

I'd like to see the

File `somefile' is not in package meta. Would you like skip/remove/edit file lists/commit/abort? (s/r/e/c/A)

part removed. I personally find it very annoying. Also, the question itself doesn't really make sense.

If you want to disable this check add "check_filelist = 0" to the "[general]" section in your ~/.oscrc. IMHO it would be better if it only checks for files which are referenced in the spec file (SourceX, PatchX etc) instead of checking all files in the working copy.

OK. I have a few suggestions then:

1. document this. I don't see a sample oscrc anywhere in the package, documenting all of the various options and such.

2. make the default, if no config item is present, to skip - this preserves backwards compatability and allows those that desire to set it up some other way.

3. Another option "warn" seems reasonable.

I couldn't agree more. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

Am Freitag, 4. September 2009 17:17:47 schrieb Jon Nelson:

I found another issue in 0.122pre.

In one project I have which is a /link/ do another, osc diff -rXX works fine. However, if I expand (osc up --expand) the project, then osc diff -rXX seems to give me /way/ more diff than is actually correct. If I unexpand then osc diff -rXX works fine again.

Hm, yes, but that is a long standing osc issue, independend to this release.

With the exception of the check_filelist issue (and the above), the new version of osc is working very well for me.

You speak about the defaults there, right ? The point was that there were quite a number of request to change exactly this due to broken submissions. I am quite unsure what to do here. Maybe we should only go with a big warning only. We anyway need to decide how to go with interaction/non-interaction mode for other stuff. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Mon, Sep 7, 2009 at 3:22 AM, Adrian Schröter wrote:

Am Montag, 7. September 2009 10:20:22 schrieb Adrian Schröter:

...

Am Freitag, 4. September 2009 17:17:47 schrieb Jon Nelson:

...

I found another issue in 0.122pre.

In one project I have which is a /link/ do another, osc diff -rXX works  fine. However, if I expand (osc up --expand) the project, then osc diff  -rXX seems to give me /way/ more diff than is actually correct. If I unexpand then osc diff -rXX works fine again.

Hm, yes, but that is a long standing osc issue, independend to this  release.

thinking again about this, what is the usecase at all ?

I mean, don't you just want to see changes, which are already commited, excluding your local changes ?

Forgive me but I'm having a hard time understanding the question exactly. However, perhaps by way of stating what I'd like to see I can answer your question. Part of the problem as I see it is that the behavior is inconsistent between an expanded and unexpanded situation. This is the part that bothers me the most - I haven't *changed* the link, but now suddenly the output of diff looks difference. What makes the most sense to me is to have diff always show the difference between the working directory and the fully patched (using the *checked in* changes) data on the server for /this/ project (not the project this is linking to). I would think that rdiff or some other command might be more appropriate to show me how this project differs from the link source, although in that situation perhaps using an /option/ instead of a different command entirely would be best to differentiate between "show me the changes between my working directory and the link source" and "show me the changes between the checked-in data and the link source." The latter is really a slightly more specific form of "show me the changes between any to arbitrary checked-in projects regardless of their relationship". Therefore, I guess I see it this way: - diff should show me the changes between my working directory and *my* (patched) copy of the project - it seems reasonable to have diff take an option to show the changes between this working directory and /any/ arbitrary project, usually the link source - it also seems reasonable to extend rdiff to be able to diff (server-side) any two arbitrary projects Your thoughts?

In that case the rdiff command is a better friend.

bye adrian

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag, 7. September 2009 15:24:08 schrieb Jon Nelson:

On Mon, Sep 7, 2009 at 3:22 AM, Adrian Schröter wrote:

...

Am Montag, 7. September 2009 10:20:22 schrieb Adrian Schröter:

...

Am Freitag, 4. September 2009 17:17:47 schrieb Jon Nelson:

...

I found another issue in 0.122pre.

In one project I have which is a /link/ do another, osc diff -rXX works fine. However, if I expand (osc up --expand) the project, then osc diff -rXX seems to give me /way/ more diff than is actually correct. If I unexpand then osc diff -rXX works fine again.

Hm, yes, but that is a long standing osc issue, independend to this release.

thinking again about this, what is the usecase at all ?

I mean, don't you just want to see changes, which are already commited, excluding your local changes ?

Forgive me but I'm having a hard time understanding the question exactly. However, perhaps by way of stating what I'd like to see I can answer your question.

osc diff -rXX tries to attempt to diff your local copy against a older revision from the server. And it fails to do this correctly when this is a source link. However, I wonder whenever you want to see an old remote revision compared to your local modifications. Maybe when you try to revert something. If you just want to see revision changes of the past commits, you should use rdiff IMHO.

Part of the problem as I see it is that the behavior is inconsistent between an expanded and unexpanded situation. This is the part that bothers me the most - I haven't *changed* the link, but now suddenly the output of diff looks difference.

Yes, and that is lacking support in the diff command, which does not handle this correctl.

What makes the most sense to me is to have diff always show the difference between the working directory and the fully patched (using the *checked in* changes) data on the server for /this/ project (not the project this is linking to). I would think that rdiff or some other command might be more appropriate to show me how this project differs from the link source, although in that situation perhaps using an /option/ instead of a different command entirely would be best to differentiate between "show me the changes between my working directory and the link source" and "show me the changes between the checked-in data and the link source." The latter is really a slightly more specific form of "show me the changes between any to arbitrary checked-in projects regardless of their relationship".

Therefore, I guess I see it this way:

- diff should show me the changes between my working directory and *my* (patched) copy of the project

That is implemented (against the last checked out version)

- it seems reasonable to have diff take an option to show the changes between this working directory and /any/ arbitrary project, usually the link source

hm, okay, that would be something new.

- it also seems reasonable to extend rdiff to be able to diff (server-side) any two arbitrary projects

That is also already supported, no ? bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org