Thread: ls*, markup and other things
Brought to you by:
tyranny
Menu
▾
▴
cvs-nserver-devel
|
From: Alexey M. <mo...@no...> - 2002-05-04 14:28:29
|
Well, yesterday I committed lsmodules subcommand so everyone are welcome to test it :-). Together w/ ls, lsacl and forthcoming lstags (Alex, don't shy as you said me a while ago, commit it please :-)) there's a complete (hopefully) bunch of commands that implements a kind of listing server (well, Michael, it's not completely 'httpd'-server as you asked but it's enough to build a remote web-frontend). I have already implemented a kind of such frontend based in CVS::Remote perl module and I hope I'll turn it eventually into viable replacement of the cvsweb and similar programs). There's an issue I want to discuss though. Current format of ls* commands are humanly readable and understandable but they can be more, hmm, formalized or smth (especially lsacl, but ls also has portability bottlenecks and so on). So my question is: do we need these commands to have an, hmm, XML-like output? If yes, what's the DTD? There're pros (we won't need an unique parser for each command) and cons (the server code needs to be more complex, there will be greater output size and so on) so final decision should be carefully discussed. Now I'm going to commit cvs-create-repository and cvs-group commands. Alex, where's the best place to put such things? A while ago my Novosoft bosses (actually it's Marod :-)) told that would be fine to have a workaround against one well-known cvs (librcs) bottleneck: when file processing time dramatically increases when there're long/complicated commit history. One possible solution for the problem is to implement (in a separated utility) a kind of purge/merge operation. This will allow us to remain compatible w/ stock cvs and solve some of the problems. The question: is there another, more convenient way? Or we should change the repository format instead and solve the problem completely?.. |
|
From: Wang J. <la...@li...> - 2002-05-06 07:44:27
|
Hello Alexey, Saturday, May 04, 2002, 10:32:41 PM, you wrote: AM> Well, yesterday I committed lsmodules subcommand so everyone are welcome AM> to test it :-). Together w/ ls, lsacl and forthcoming lstags (Alex, AM> don't shy as you said me a while ago, commit it please :-)) there's a AM> complete (hopefully) bunch of commands that implements a kind of listing AM> server (well, Michael, it's not completely 'httpd'-server as you asked AM> but it's enough to build a remote web-frontend). AM> I have already implemented a kind of such frontend based in CVS::Remote AM> perl module and I hope I'll turn it eventually into viable replacement AM> of the cvsweb and similar programs). AM> There's an issue I want to discuss though. Current format of ls* AM> commands are humanly readable and understandable but they can be more, AM> hmm, formalized or smth (especially lsacl, but ls also has portability AM> bottlenecks and so on). So my question is: AM> do we need these commands to have an, hmm, XML-like output? If yes, AM> what's the DTD? There're pros (we won't need an unique parser for each AM> command) and cons (the server code needs to be more complex, there will AM> be greater output size and so on) so final decision should be carefully AM> discussed. I don't think output of XML-like format is good. The pros doesn't buy cons. AM> Now I'm going to commit cvs-create-repository and cvs-group AM> commands. Alex, where's the best place to put such things? AM> A while ago my Novosoft bosses (actually it's Marod :-)) told that would AM> be fine to have a workaround against one well-known cvs (librcs) AM> bottleneck: when file processing time dramatically increases when AM> there're long/complicated commit history. One possible solution for the AM> problem is to implement (in a separated utility) a kind of purge/merge AM> operation. This will allow us to remain compatible w/ stock cvs and AM> solve some of the problems. The question: is there another, more AM> convenient way? Or we should change the repository format instead and AM> solve the problem completely?.. -- lark |
|
From: Alexey M. <mo...@no...> - 2002-05-06 16:35:14
|
=F7 =F0=CE=C4, 06.05.2002, =D7 14:44, Wang Jian =CE=C1=D0=C9=D3=C1=CC: > AM> bottlenecks and so on). So my question is: > AM> do we need these commands to have an, hmm, XML-like output? If yes, > AM> what's the DTD? There're pros (we won't need an unique parser for eac= h > AM> command) and cons (the server code needs to be more complex, there wi= ll > AM> be greater output size and so on) so final decision should be careful= ly > AM> discussed. > I don't think output of XML-like format is good. The pros doesn't buy > cons. Well, I'm also not sure that XML is the way to go. But current format of lsacl makes me feel terrible. Smth definitely should be changed but don't know how... Technically speaking a carefully designed and well-defined XML DTD doesn't give the server too much additional work. / and // used now as separators will be changed to number of <> " etc... Probably there's a better solution though... Any suugestions? > AM> Now I'm going to commit cvs-create-repository and cvs-group > AM> commands. Alex, where's the best place to put such things? Well, we have discussed this in ICQ and decided that perl modules will go to perl, web-interface will go to web/ or www/ and admin tools - to tools/. Tomorrow morning I'll start to commit things so everyone is welcome to test and improve. Particularly improvements will be needed for System::Account module which helps to create system accounts (via call to appropriate system tools like useradd). Different systems are supported via in-module database which describes tools names and switches. I added support for linux/redhat account tools (useradd and groupadd), support for other system is still missing but hopefully easy to add. |
|
From: Alexey M. <al...@hs...> - 2002-05-09 13:08:58
|
>>>>> "AM" == Alexey Morozov <mo...@no...> writes: AM> Technically speaking a carefully designed and well-defined XML DTD AM> doesn't give the server too much additional work. / and // used now as AM> separators will be changed to number of <> " etc... AM> Probably there's a better solution though... Any suugestions? We could start with formal definition of how are the ACLs stored in repository, on abstract level. I must admit that 'cvs lsacl' is totally ad hoc, because it does not take into account the module-level ACLs and the repository policy. AM> tools/. Tomorrow morning I'll start to commit things so everyone is AM> welcome to test and improve. Particularly improvements will be needed AM> for System::Account module which helps to create system accounts (via AM> call to appropriate system tools like useradd). Different systems are AM> supported via in-module database which describes tools names and AM> switches. I added support for linux/redhat account tools (useradd and AM> groupadd), support for other system is still missing but hopefully AM> easy to add. Please write some wrap-up of the web-interface: how to set it up, basically. After that somebody will take a look at it wrt making it more "redistributable". We need the release! :) 1.11.1.53 will be broken, that's for sure. --alexm |
|
From: Alexey M. <al...@hs...> - 2002-05-09 13:08:52
|
>>>>> "WJ" == Wang Jian <la...@li...> writes: AM> There's an issue I want to discuss though. Current format of ls* AM> commands are humanly readable and understandable but they can be more, AM> hmm, formalized or smth (especially lsacl, but ls also has portability AM> bottlenecks and so on). So my question is: do we need these commands AM> to have an, hmm, XML-like output? If yes, what's the DTD? There're AM> pros (we won't need an unique parser for each command) and cons (the AM> server code needs to be more complex, there will be greater output AM> size and so on) so final decision should be carefully discussed. WJ> I don't think output of XML-like format is good. The pros doesn't buy WJ> cons. Well, first I too was against the XML. Now, I think that XML is viable option (of course, not via full libxml, simply printf-style ;). The thing is that the recipients of the 'cvs lsacl' command are usually some web front-ends, which are written in Perl as the very least (but could be simply done with Java/XSLT, if needed (so we could do the direct transformation of the ACLs to webpage!)). I hope that Perl finally caught up with XML parsing with Java at last (AFAIH, two years ago it was almost inadequate). So, the server-side XML handling is very simple, while the client-side XML handling is completely standalone and we should not bother about _its_ bloat. Currently Alex is the primary customer of the 'cvs lsacl' command and it seems to me he hates its output :) --alexm |
|
From: Alexey M. <mo...@no...> - 2002-05-10 16:03:22
|
=F7 =FE=D4=D7, 09.05.2002, =D7 20:01, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC=
:
> Now, I think that XML is viable option (of course, not via full libxml,
> simply printf-style ;).
Sure. we don't need XML parsing at all. Just printf("<some=20
attribute=3D"value">\n") instead of printf("some attribute was assigned to
value eventually\n") :-))
> So, the server-side XML handling is very simple, while the client-side XM=
L
The only thing we need is some kind of URL escaping (probably
simplified, just % -> %25, " -> %22, > -> %3E, hmm, looks that's enough
for everything (C):-))
> handling is completely standalone and we should not bother about _its_
> bloat.
Somebody shouldn't, somebody should :-)
> Currently Alex is the primary customer of the 'cvs lsacl' command and it
> seems to me he hates its output :)
A-a-a-ah, "dislike" :-)
|
|
From: Alexey M. <al...@hs...> - 2002-05-10 00:02:05
|
>>>>> "AM" == Alexey Morozov <mo...@no...> writes:
AM> A while ago my Novosoft bosses (actually it's Marod :-)) told that
AM> would be fine to have a workaround against one well-known cvs (librcs)
AM> bottleneck: when file processing time dramatically increases when
AM> there're long/complicated commit history. One possible solution for
AM> the problem is to implement (in a separated utility) a kind of
AM> purge/merge operation. This will allow us to remain compatible w/
AM> stock cvs and solve some of the problems. The question: is there
AM> another, more convenient way? Or we should change the repository
AM> format instead and solve the problem completely?..
Huh? You mean purging intermediate revisions that are, say, older than
certain date? This could be done simply with 'cvs admin -o' (an option
inherited from the RCS).
man rcs:
-orange
deletes ("outdates") the revisions given by range.
A range consisting of a single revision number
means that revision. A range consisting of a
branch number means the latest revision on that
branch. A range of the form rev1:rev2 means revi╜
sions rev1 to rev2 on the same branch, :rev means
from the beginning of the branch containing rev up
to and including rev, and rev: means from revision
rev to the end of the branch containing rev. None
of the outdated revisions can have branches or
locks.
Of course, that's maybe kind of extreme to do this, though maybe
practical.
In the long term rewriting of librcs could be considered, surely :) It
could create all sorts of temporary files and indices near the master
,v-file. I do not think that such decision should be taken lightly, though
it could have a lot of advantages.
--alexm
|
|
From: Alexey M. <mo...@no...> - 2002-05-10 15:26:53
|
=F7 =F0=D4=CE, 10.05.2002, =D7 07:01, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC= : > Huh? You mean purging intermediate revisions that are, say, older than > certain date? This could be done simply with 'cvs admin -o' (an option > inherited from the RCS). Well, almost but not completely. One needs to be able to save parts of rcs files that are going to be removed and be able to restore them upon a request... Well, I understand that this functionality shouldn't be put into server but rather into admin scripts instead. > Of course, that's maybe kind of extreme to do this, though maybe > practical. >=20 >=20 > In the long term rewriting of librcs could be considered, surely :) It > could create all sorts of temporary files and indices near the master > ,v-file. I do not think that such decision should be taken lightly, thou= gh > it could have a lot of advantages. :-). The Proper Way is not a light thing anyway :-) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X