set fd [open .svn/entries]
set xml [read $fd]
close $fd
set revision [GetXmlAttribute [xml2list $xml] "wc-entries:entry" revision]
done...
Actually, this will only return the first element, we assume here the
first entry is the entry for the whole svn checkout, but we'd actually
need to use the sxml engine with a callback routine to parse the xml file,
so a
set id [::sxml::init [file join .svn entries]]
::sxml::register_routine $id "wc-entries:entry" got_svn_entry
::sxml::parse $id
::sxml::end $id
but it won't work for one stupid reason, the sxml engine supposes that
each line contains a tag, so a
<entry
name=""
revision="6367"
/>
won't work, it really wants
<entry name="" revision="6367"/>
so I've been trying to fix it, but I need to go now, I think changing the
way the sxml works would be a good idea... then we'd need to parse the
.svn/entries file
looking at it makes it look very simple, you have a main wc-entries tag,
in which you have an <entry> tag showing the revision number of each file,
the filename being in the 'name' attribute of the tag... if the name=""
empty string, then the attribute 'revision' is the overall revision of the
svn copy...
simple!
btw, for the xml2list to work, you need a little change I just commited to
svn...
KKRT
On Mon, 29 May 2006 21:47:39 -0400, Youness Alaoui
<[EMAIL PROTECTED]> wrote:
> well, it would need some tweaking indeed, but yes, THANKS to the XML
> system, we can add a tag without breaking anything! :)
> so a new tag would be nice, being able to sort by revision number would
> be
> nice.. when setting something to fixed, be able to set which revision it
> was fixed on (now it uses the date of modif, be we can't use that
> anymore)...
> when we set something to fixed, we should keep one bug report in it, and
> delete all other reports...
>
> KaKaRoTo
>
> On Mon, 29 May 2006 19:18:00 -0400, Karol Krizka <[EMAIL PROTECTED]>
> wrote:
>
>> On Mon, 2006-29-05 at 15:39 -0400, Youness Alaoui wrote:
>>> Yes, but the file is not read... you should read the svn_rev file, if
>>> it
>>> doesn't exist, then try the svn command, if it doesn't exist, then use
>>> the
>>> $::date
>>> also, the revision number is not a date, so watch out for that, it may
>>> crash the bug reporting if the DB assumes it should receive a date, not
>>> a
>>> string...
>>>
>> It won't crash it, just bug reports will be very old. A simple fix would
>> be to update the version of the bug report being sent and add the
>> revision # in a new "<svn_revision>" tag. I'll have the bug report
>> figure out by version which field it should look into.
>>
>>> KaKaRoTo
>>>
>>> On Mon, 29 May 2006 15:15:00 -0400, Sander Hoentjen
>>> <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>> > On Tue, 2006-05-30 at 00:19 +1000, Arieh Schneier wrote:
>>> >> Aren't you assuming that the user has svn support installed and is
>>> >> using the
>>> >> svn version? What about all the users that use the packages, or the
>>> >> tarball?
>>> >>
>>> > Yes I am asuming that. In packages and the tarball there should be
>>> this
>>> > info included.
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Amsn-devel mailing list
>> Amsn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
>
>
--
KaKaRoTo
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
