new status output

[John A Meinel]

James Blackwell wrote:
> James Blackwell wrote:
>
>>>Added Renamed Modified             somedirectory/subdir/anotherdir/
>>>file
>>>                      Conflicted  somedirectory/subdir/anotherdir/
>>>file2
>>>
>>>(one keeps different types of changes in different fields for easy
>>>parsing
>>>by external third party programs)
>
>
> On Tue, Oct 25, 2005 at 10:04:04AM -0700, Robey Pointer wrote:
>
>>I don't think that's true.  If I were writing a script, I'd find the
>>odd spacing more difficult than just words.  But either way, the idea
>>is more like:
>>
>>renamed   somedirectory/subdir/file => somedirectory/subdir/file1
>>modified  somedirectory/subdir/file1
>>added     somedirectory/subdir/file2
>
>
> What do you do if something is both renamed and modified?

That is exactly what he has written. The file shows up twice. (It was
renamed to file1, and then it was marked as modified *as* file1).

>
> The field concept is a rather common one as it works well in C land.
> Consider this all-too-sloppy, unflexible and untested c code:
>
> #define READ_FLAG_LENGTH 20
> #define READ_FLAG_OFFSET 20
> #define BUFFER_LEN 255
>
> char * linein;
> char * read_flag;
>
> linein = malloc(BUFFER_LEN + 1);
> read_flag = malloc(READ_FLAG_LENGTH+1);
> while (fgets linein from stdin)
>   {
>      strncpy(read_flag, linein+READ_FLAG_OFFSET, READ_FLAG_LENGTH);
>      read_flag+READ_FLAG_LENGTH=0
>   }
>
> One can see many slightly examples of this in /proc, though they're less
> limited in the number of fields. Typically they come with field headers as
> well.
>
>
>>There's no need to pile up all of a file's changes on one line.  In
>>some cases (like rename), extra info is helpful anyway.
>>
>>And now that I've said all that, I have to deflate by saying that I'm
>>actually okay with the current system of changes files out by
>>categories. :)
>
>
> As I mentioned before, this isn't such a hot idea for third party
> programs, since it requires at least a minimal state machine.
>

I think a decent interface is just the "bzr ls --unknowns", if you don't
want a state machine. My only concern is possibly performance issues if
you have to run a lot of them in a row, and bzr might be slow on a big tree.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051025/e933c65a/attachment.pgp