that certainly tastes something that could be wishable but I wonder if  
there's not something hidden here.
I haven't heard of many "virtual subversion servers", have you?

The worst hidden bit is, in my current practice, that all our sources  
are, of course, in our subversion repository anyways so one would need  
to start the multiple-subversion-business (svk maybe?) which is  
considerably less robust than svn as far as I know.

paul


Le 29-déc.-09 à 01:24, Niels Mayer a écrit :

> What about having a "virtual" subversion checkin URL associated with  
> any
> Xwiki site. There's be a restricted set of files that could be  
> checked in,
> where most Xwiki documents are ".vm" files -- velocity macro.
>
> The subversion protocol, which is just HTTP, would actually be  
> implemented
> in Xwiki, such that subversion checkins would checkin a new version  
> (doing
> all the xml-encoding and name-fixing needed for storage in xwiki's  
> db). A
> subversion checkout would de-encode the XML and reverse-name-fix for  
> 1-1
> correspondence with the checked-in file. Fancier subversion protocol
> functionalit like diffs and retrieving revs, etc could all be "not
> implemented" but the basics of checkin/checkout to the "head" would  
> still
> work. Most of subversion's "RCS" facilities are already implemented in
> Xwiki's document store,  so this proposed feature would represent a  
> bridge
> between subversion and the document store. The user would end up using
> whatever preferred  GUI frontend (or commandline) svn tools  
> available....
>
> There'd be numerous limitations on this virtual  subversion store  
> that would
> just cause it to "error out" if inappropriate filenames or  
> directories are
> attempted checkin (e.g. "." in the name). Errors would also occur w/  
> invalid
> xwiki db read/write perms for the checkin user. Further, the special
> subversion repo would also only implement one level of "directory"
> (representing xwiki spaces) and would require that any non-vm files  
> (aka
> attachments) have a valid path representing the document name (minus  
> vm
> exptension). e.g. /<space>/<document>/<attachment>.<ext> for
> all /<space>/<document>.vm
>
> Niels
> http://nielsmayer.com
>
>
>
> On Sat, Dec 26, 2009 at 4:16 PM, Andreas Schaefer <[email protected]>  
> wrote:
>
>> Hi
>>
>> For the development of the Groovy based Blog I just developed the  
>> code in
>> IntelliJ, copied inside a browser and eventually exported the  
>> content into a
>> XAR file. Slowly but surely this is getting way to much work  
>> especially when
>> doing sweeping changes.
>>
>> Because I don't use Eclipse I am not able to use the XEclipse tool  
>> but I
>> was wondering if anybody knows a way to XML encode text (within  
>> Maven2) so
>> that it later could use Ant's copy and filter tool to incorporate the
>> developed code / content inside the XML file that will build up the  
>> XAR
>> file.
>>
>> Thanks - Andy
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to