Hi!
RalucaM and myself have been working on/reviewing French translations
for XWiki 4.3 and we've posted a report illustrating the issues we
found here http://www.xwiki.org/xwiki/bin/view/TestReports/TranslationsReport43
Sorin will be reviewing each entry to see whether translations or keys
are missing and will probably ping you on IRC for help :)
It would be very useful however if you could look at the reported
issues and make some of the needed fixes, especially if you're a
native French speaker.
Edi has already helped us with the Workspaces App keys. Thanks a lot!
Please reply to the current thread and specify the fixes you've made,
or edit the document directly and write [fixed] in front of the entry
you handled. We won't be able to include the translations in the 4.3
final release, but it would be wonderful if we could have a 4.3.1, or
even include them in 4.4.
Here is the link again:
http://www.xwiki.org/xwiki/bin/view/TestReports/TranslationsReport43
Translation wiki: http://l10n.xwiki.org/xwiki/bin/view/L10N/
Thanks,
Silvia
Hi devs,
I'd like to deprecate Util.getResourceAsStream():
public static InputStream getResourceAsStream(String resource)
{
File file = new File(resource);
try {
if (file.exists()) {
return new FileInputStream(file);
}
} catch (Exception e) {
// Probably running under -security, which prevents calling File.exists()
LOGGER.debug("Failed load resource [" + resource + "] using a file path");
}
try {
Environment environment = Utils.getComponent(Environment.class);
InputStream res = environment.getResourceAsStream(resource);
if (res != null) {
return res;
}
} catch (Exception e) {
LOGGER.debug("Failed to load resource [" + resource + "] using the application context");
}
return Thread.currentThread().getContextClassLoader().getResourceAsStream(resource);
}
Instead I'd like to propose to use the new Environment.getResourceAsStream(). However I'd also like to modify the ServletEnvironment.getResourceAsStream() implementation so that it also looks in the classloader if not found in the resources directory (defaulting to the current thread context class loader for the classloader to use since this is set in a servlet container).
Thanks
-Vincent
Hello,
Is it possible to use Sencha JS as a front-end resource to build in-wiki applications ?
Nweike Onwuyali
.............................
excuse my typos & brevity. Sent from a mobile device
Hello all, I am new to xwiki
Can I use xwiki to build a social networking site like elgg
Nweike Onwuyali
.............................
excuse my typos & brevity. Sent from a mobile device
Hi devs,
I'd like to rename the "Release Plans" app (http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/WebHome) into "Releases" (i.e. remove the "plan" part) and then commit in platform as an application.
Here's my +1
Thanks
-Vincent
PS: This action goes in the direction of creating a list of useful applications/extensions for a Project Development Flavor (see other mail).
Hi devs,
While debugging the failing Selenium tests, most of which are
flickers, I "discovered" a behaviour that I was not aware of. It looks
like when you ask Selenium to click on an element from the page it
does the following:
* locate the element in the DOM
* compute the bounding rectangle (and thus determine if the element is visible)
* scroll the element into view if needed
* move the mouse in the center of the bounding rectangle
* fire a click event with the mouse coordinates
There are two important things to note:
(1) The click event is not bound to the element. The browser behaves
as if the user clicked at that position (x, y) on the page, on
whatever is displayed on top.
(2) The click command doesn't seem to be atomic (i.e. the element
position can change between the moment its bounding rectangle is
computed and the moment the click event is fired).
This allows for the following to happen:
(i) The floating content/edit menu can silently prevent elements to be
clicked (if the page is scrolled and the element is at the top of the
window and the middle of the element is right beneath the floating
menu).
(ii) Clicking on buttons before the page layout is stable can fail
silently. For instance, clicking on Save & View before the WYSIWYG
edit mode is fully loaded can fail silently because the position of
the button is not stable.
Moreover, it seems that the mouse position is "remembered" between
page loads and the browser reacts to it. For instance, if you click on
"Back to edit" in preview mode (and don't move the mouse) the mouse
can end up above the edit menu thus opening it which in turn prevents
you from clicking on the Link menu from the WYSIWYG editor tool bar
(you end up in Object or Class edit mode..).
I'm not sure if this is something introduced in a recent version of
Selenium or if it was triggered when I enabled native events.
Thanks,
Marius
Hi,
A couple weeks ago I proposed a technique for allowing servlets to be registered with the component
manager. There was some tentative agreement that the idea had merit so I began researching it.
In the process of trying to solve this problem I think I have stumbled on a workable Actions2.0 model.
The really short version:
@Component
@Named("sayhello")
public class HelloWorldAction implements Action
{
@Action.Runner
public void run(ClientPrintWriter cpw)
{
cpw.println("Hello World!");
}
}
The Action router gets a request for localhost:8080/xwiki/sayhello/ and loads your Action from the
ComponentManager, it examines the class and sees your annotated method and looks at it's arguments,
since the method takes a ClientPrintWriter, the action router gets a list of all ActionProviders
from the ComponentManager and examines them to find one which provides it. It then uses the same
technique to recursively resolves that provider's requirements. Once all requirements have been
satisfied, the router calls each provider and finally your Action, each time passing the required
dependencies using the Method#invoke() function.
Here's an example of an ActionProvider which provides a PrintWriter:
@Component
@Named("ServletPrintWriterProvider")
public class ServletPrintWriterProvider implements ActionProvider
{
@Action.Runner
public void run(ServletResponse resp, Callback<ClientPrintWriter> cpwCallback)
{
cpwCallback.call(new PrintWriter(resp.getOutputStream()));
}
}
Obviously one could be registered which worked with Portlet, or even command line invocation.
HelloWorldAction doesn't require much.
Benefits of this design:
1. You only get what you need. Why should I wait for the XWikiContext or the ExecutionContext to be
populated so that I can serve the user a static piece of js or a favicon?
2. Legacy code can coexist with modern code. If there is an ActionProvider which provides an
XWikiContext then all legacy code is about 8 lines away from comparability. Same is true for code
which absolutely needs a ServletRequest and ServletResponse, they just need to require them.
3. This API doesn't try to own you. You're not tied down to a context with specific values in it.
If you are requiring a PotatoeContext and it turns out not to be good enough, write a CarrotContext
and begin requiring that, the Action model is still the same.
Devil's Advocacy:
1. Why does it map implementations by their classes? What if someone wants to register 2 providers
of OutputStream?
* Notice I used ClientPrintWriter rather than PrintWriter in the example. If you write a provider,
it is best practice to extend a class or interface and provide your extension so that anyone who
is using your provider will have to 'import' the class which you provide.
I want to avoid this: Object x = context.get("IHaveNoIdeaWhereThisIsDefined");
We can change this without breaking the API by adding optional "hints" to the @Action.Runner
annotation.
2. Good job cjd, you just rewrote the ComponentManager.
* I spent quite some time wrestling with whether this should be done in the CM, from a pragmatic
PoV, the problem is you end up needing to create things on a per-request basis which abuses the
ECM and will hold the initialization (global) lock for a long time. From a design PoV it's wrong
because dependency injection is meant to inject long lived (often singleton) machinery objects
whereas this is for request scoped data objects.
3. Why the silly Callbacks?
* An obvious thought is that an ActionProvider should just have a get() method like any other
provider which returns the object in question. The pragmatic issue with that is suppose you need
to do something expensive like hit the database to get an object and you get another object for
free while doing it, do you throw the other one away and then when the caller needs the other
one, they call another provider and do the expensive operation over again? This solution allows
a provider to pull in multiple callbacks and call each one, thus providing multiple objects.
A second more subtle reason is that ActionProviders are allowed to return their provisions
asynchronously which means we could implement some very exciting optimizations at the storage
level. We don't have to do that route but I don't want to close the door on it.
4. Nobody has ever done this before
* That's why it's going to work.
Actually this design draws heavily on Asynchronous Module Definition which is explained here:
http://requirejs.org/docs/whyamd.html
5. Magic! Arrest this sorcerer!
* It's valid to call this magic. It's also valid to call any kind of dependency injection magic.
@Inject private InterfaceWhichDoesNotExplainMuch youWillNeverFigureOutWhereTheImplementationIs;
is as bad as this or worse. One way we can minimize the magic and keep the benefits is to make
our ActionProviders provide custom classes which are defined close to the ActionProvider.
ViewingUser or CurrentDocumentAuthorUser are much more self explanatory than injecting "User"
even if both classes extend User.
5. ...
* Help me try to break this design.
Where's the code:
Coming soon, I have most of a PoC hacked together but it currently has a slightly different API
which I scrapped in favor of the one defined here. I just want to get discussion going as early
as possible.
Prove me wrong
Caleb
Hi devs,
I've started an experiment to have colocated functional tests (CFT), which means having the functional tests located where the functional domain sources are located instead of in XE.
For example for the linkchecker module we have the following directories:
xwiki-platform-linkchecker/
|_ xwiki-platform-linkchecker-refresher (JAR)
|_ xwiki-platform-linkchecker-ui (XAR)
|_ xwiki-platform-linkchecker-tests (functional tests)
The rationale for this was:
* Have everything about a functional domain self-contained (source and all tests)
* Making it easy to run only tests for a given functional domain
* Move page objects to the functional domain too
Here are some findings about this experiment:
A - It takes about 30 seconds to generate the adhoc packaging and start XWiki. This would be done for each module having functional tests compared to only once if all tests were executed in XE
B- The package mojo created to generate a full packaging is quite nice and I plan to reuse it in lots of other places in our build (distributions, database, places where we need XWiki configuration files)
C- We will not be able to run platform builds in Maven multithreaded mode since it would mean that several XWiki instance could be started at the same time on the same port
D- The colocated functional test module
Solutions/ideas:
* One idea to overcome A and C would to have the following setup:
** Keep functional test modules colocated but have them generate a test JAR
** Still allow running functional tests from the colocated module (this makes it easy to verify no regression was introduced when making changes to a given domain)
** Have functional tests in XE depend on the colocated functional test module JARs and configure Jenkins to run all functional tests from XE only
* Another solution to overcome C is to auto-discover the port to use in our XWiki startup script (and save it in a file so that the stop script can use it).
I think the first proposal is the best one and brings the best of the 2 worlds.
WDYT?
Thanks
-Vincent
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxsw I
would like to extract the query plugin from xwiki-platform-legacy-oldcore
and move it to retired repository.
The good things is that we will get rid of 3 jars in standard XE by doing
this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1
--
Thomas Mortagne
Hello,
I'm working on the JIRA issue "Automatically register translations
for the Bulletin Board application", and so I would like to be able to
access the Bulletin Board application. Could you let me access it from my
GitHub account ? My GitHub UserName is "tDelafosse".
Cheers,
Thomas
>
Hi devs,
I had to modify Selenium 1 tests to run on WebDriver because otherwise
WYSIWYG tests were not running on Firefox version newer than 11 and
this was holding ui-tests (Selenium 2 / WebDriver) tests back. Right
now all CI agents are using Firefox 11 which is a bit old. We could
configure CI to run Selenium 1 and 2 tests on different browsers, but
I'd rather use the same browser.
This is the first step of migrating all Selenium 1 tests to WebDriver.
I'd like to merge my commits into the stable-4.3.x branch because it
doesn't affect the stability of the end product (XE) and it eases the
configuration of the CI
See http://jira.xwiki.org/browse/XE-1252 and
https://github.com/xwiki/xwiki-enterprise/commit/811cd70797141d93f062b73907…
Here's my +1
Thanks,
Marius
I want to make such a Comparator so that I can sort objects retrieved by
$xwiki.getObjects("Class")
If I had the Comparator, I'd be able to pass it to a collection sort method
and sort objects.
I'm planning to make that Comparator in a groovy snippet.
I may be able to make a Component for that even.
Is it possible?
If it was possible, would you give me some hints?
Hello everyone,
I'm trying to write a listener. The listener is correctly triggered after
creation. But when I change the listener code, it is not taken into account
by the server. I have to
restart the server. How to avoid this?
This my code:
{{groovy}}
import org.xwiki.observation.*
import org.xwiki.observation.event.*
import com.xpn.xwiki.web.*
import com.xpn.xwiki.*
class AutoEventListener implements EventListener
{
def xwiki
def context
AutoEventListener(xwiki, context)
{
this.xwiki = xwiki
this.context = context
}
String getName()
{
return "auto_febi"
}
List<Event> getEvents()
{
return Arrays.asList(new DocumentSaveEvent())
}
void onEvent(Event event, Object source, Object data)
{
if (source.fullName != "EventListenerAuto") {
def document = xwiki.getDocument(source.fullName)
def var= document.getValue("avisDSI")
if (var != "-"){
document.set("nomDSI","coucou")}
}
}
}
def observation = Utils.getComponent(ObservationManager.class)
observation.removeListener("auto_febi")
def listener = new AutoEventListener(xwiki, xcontext)
observation.addListener(listener)
{{/groovy}}
Thank you very much for your future answer,
Cécile
--
View this message in context: http://xwiki.475771.n2.nabble.com/listener-not-reloading-after-modification…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Can I use $services.xml to parse a XML document to get the tag name and
value?
#set( $xml = "<test><input1>eeee</input1></test>");
I would like the input value "eeee". How can this be done?
Thanks,
Patrick
--
View this message in context: http://xwiki.475771.n2.nabble.com/question-about-xml-tp7582405.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
I am upgrading from Xwiki 2.7.33656 to Xwiki 4.3-milestone-1.
I also upgraded from Tomcat 5.5.33 to Tomcat 7.0.32.
I installed the Xwiki as a WAR in the new instnace of Tomcat. I modified
the hibernate.cfg.xml file as indicated in the install instructions.
When trying to access the new Xwiki it just sits on a blank page with
reference to http://localhost:8080/xwiki/bin/view/Main/.
I did try to run the MYSQLDUMP file from the older Xwiki instance in the
newer Xwiki instance.
But each time it fails with "lost connect to mysql".
Is there some difference between the MySQL databse instances of Xwiki 2.7.*
and Xwiki 4.3* that could be causing this problem?
Some of the log files are below...
*catalina*.log
*Nov 14, 2012 11:24:24 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 29542 ms
*localhost_access_log*
0:0:0:0:0:0:0:1 - - [14/Nov/2012:11:41:36 -0600] "GET /xwiki/ HTTP/1.1" 302
-
0:0:0:0:0:0:0:1 - - [14/Nov/2012:11:41:36 -0600] "GET /xwiki/bin/view/Main/
HTTP/1.1" 200 -
*localhost.log*
Nov 14, 2012 11:23:55 AM org.apache.catalina.core.ApplicationContext log
INFO: ContextListener:
attributeAdded('org.apache.jasper.compiler.TldLocationsCache',
'org.apache.jasper.compiler.TldLocationsCache@2b9406')
--
View this message in context: http://xwiki.475771.n2.nabble.com/Blank-Xwiki-after-upgrading-from-2-7-3365…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
I took a look at the new model proposal and there are a few questions and suggested changes.
https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor…
Should this be a String rather than a Java UUID type?
https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor…
If we use getChildren() rather than getChildReferences(), we will be mangling the model with the database code which violates the MVC principle.
Also we run the risk of encouraging users to walk the tree looking for the entity it wants rather than creating a reference to it and using that.
Walking the tree would obviously incur enormous unnecessary database load.
https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor…
Do we want to continue with the concept of the global variable representing the "current" document?
I'm currently not brimming with alternative ideas but the heavy reliance on the XWikiContext has lead to
a lot of inter-modular communication which makes oldcore difficult to maintain, perhaps we can prevent
this in the new model.
https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor…
I would rather this have a name which doesn't collide with a java.lang class. When I see Object in a .java
file I would like it to always mean java.lang.Object.
https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor…
I like XClass better for this purpose, it is essentially a class and creating a new name which nobody
has ever heard of will just steepen the learning curve and make things hard on newcomers.
https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor…
Why not give the user direct access to the property without the intervening wrapper?
https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor…
I don't like this.
A Persistable is saved in a store by a user. Who is the user and where are they saving it?
What if I want to have multiple stores?
Must there be a global variable representing the store which is implied by this function?
The comment and minorEdit fields are also a bit dubious, perhaps in the future they will make no sense, perhaps
they should really be attributes of the Document, also the "attributes" parameter reminds me of this:
http://geek-and-poke.com/2012/06/how-to-create-a-stable-api.html
Finally, giving the document awareness of where and how it is stored violates the MVC boundries.
I think we should not worry about the API which stores the Persistable when we are creating the model, the
store API should be separate so that it can evolve while the model stays stable.
https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor…
A session is essentially a transaction? If so why not call it Transaction? Also why does it extend Persistable?
How do you persist a session?
https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor…
Why does addSpace() not take a Space parameter? it makes sense to me that you would do:
parent = storeApi.get(wikiRef, "SomeSpace", user);
child = new DefaultSpace();
child.addDocument("ADocument", new DefaultDocument("This is content."));
parent.addSpace("ChildSpace", child);
storeApi.save(parent, user);
I'm just brainstorming here but this seems like a reasonable approach..
I noticed the lack of a User data type, is that just something which is planned for the future or is it
intentionally missing?
Thanks,
Caleb
The XWiki development team is proud to announce the availability of XWiki
Enterprise 4.3 Milestone 2.
This release brings:
- a new and experimental Solr Search engine
- new default date, user and group pickers
- a new localization module allowing applications to register translations
- REST API additions
- various other improvements.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki43M2
Thanks
-The XWiki dev team
Hi devs,
I'm writing functional tests for the FAQ app in platform and I wanted to write a test for verifying that the app registers itself in the app panel.
The problem is that the app panel requires UI extensions and the app panel is currently located in the panels app. However I don't want to put that as a dependency on UI extensions in the panels app since no other panel need it.
So the good answer is that the app panel is not correctly located. Actually the panels ui app should only contain the Panels.WenHome page and all other panels should be part of the other functional domains…
So that brings me to this proposal which is:
* Create a new xwiki-platform-application/ which represents the functional domain of wiki applications.
* Have 3 submodules in it as follows:
xwiki-platform-application/
|_ xwiki-platform-application-manager/
|_ xwiki-platform-application-manager-api/
|_ xwiki-platform-application-manager-ui/
|_ xwiki-platform-application-appwithinminutes/
|_ xwiki-platform-application-ui/
* ATM xwiki-platform-application-ui/ would contain only the Applications Panel but in the future the content of xwiki-platform-application-manager-ui/ should be merged with it and it should for example provide a UI to list all apps in the wiki.
* In the future xwiki-platform-application-manager-api/ would also be renamed in xwiki-platform-application-api/
Here's my +1
Thanks
-Vincent
Devs,
Since 4.4 M2 has been released yesterday, I propose to release 4.3 RC1
this friday instead of today.
Please make sure you don't commit new stuff after tomorrow evening and
help stabilize the build.
Thanks
Jerome
Hi devs,
Since the current policy is to ask before adding a CLIRR exclude and since
I did not ask when I applied GuillaumeD's pull request [1], I hereby ask
for your vote whether it is ok to exclude the 2 new methods:
- that allows the creation of workspaces using a different template than
the default one
- that lists workspace templates
Since we are tight with time (Fabio needs to finish the 4.3M1 release),
this issue should be settled ASAP.
Also, please note that the Workspace API is still young (and pretty basic),
as far as I am concerned, and it is bound to get updated in the future.
Here's my +1
Thanks,
Eduard
--------
[1] https://github.com/xwiki/xwiki-platform/pull/70
Le 9 mars 2012 16:59, "Vincent Massol" <vincent(a)massol.net> a écrit :
>
>
> On Mar 2, 2012, at 10:06 AM, Denis Gervalle wrote:
>
> > On Wed, Feb 29, 2012 at 08:19, Vincent Massol <vincent(a)massol.net>
wrote:
> >
> >> Hi,
> >>
> >> On Feb 28, 2012, at 12:17 PM, Thomas Mortagne wrote:
> >>
> >>> Hi devs,
> >>>
> >>> Since I plan to move some stuff from platform to commons I would like
> >>> to know what you think of the history in this case.
> >>>
> >>> Pros including history:
> >>> * can access easily the whole history of a moved file.
> >>
> >
> > This is really an important matter, especially for those joining the
> > project. When you follow XWiki from "outside", and not in a continuous
> > manner, the history is of great value to understand why stuffs are like
> > they are, and what you may do, or not when moving forward.
>
> The history is not lost. If you do a join (all active repos) you still
have it.
I do not know what you means by joining all repos, but I would be surprise
to see the IDE find its way between them. I even wonder how it could be
possible.
>
> >> But sometimes
> >>> changing packages etc make too much difference for git to see it's
> >>> actually the same file so you loose it anyway.
> >>
> >
> > If you simply change the package name, and nothing else, it is really
> > unlikely to happen.
> >
> >
> >>>
> >>> Cons including history:
> >>> * double the history which make tools like ohloh indicate wrong
> >> informations
> >>
> >
> > Sure, the stats will be broken, but what is the matter. This is not
> > cheating, just a misfeature in Ohloh, since the commit are just
identical,
> > something they may notice. IMO, this is the matter of the statistical
tools
> > to improve that.
>
> Can you tell me how to implement this because right now my GitHub tool
doesn't do that and I don't know how to do it?
If I had to implement it, I will probably use some hashing method to be
able to recognize similar commits, since there effectively no link between
them. But my main remarks that the statistics are broken, not the way we
use git.
>
> >>> * it's a lot easier to move without history
> >>
> >
> > There should be some tools to improve that point or we may write one,
once
> > for all. So this is not a real cons either.
>
> It's really hard to copy history in Git. It's almost impossible to do it
right. You have to remember the full history and it's just too hard.
I would be really disappointed to have to conclude that. There is probably
some edge cases, but most of the time there is clever work around. You have
to talk to Sergiu :-)
>
> >>> WDYT ?
> >>>
> >>> Even if it was looking a bit weird to me at first I'm actually +1 to
> >>> not move the history in this case.
> >>
> >> +1, FTR I'd be -0, close to -1 to move it. If/when the source
repository
> >> is removed for one reason or another, then we might want to import its
> >> history somewhere.
> >>
> >
> > Seems we are really opposite on this one, since I am close to -1 to not
> > move it.
>
> Sorry but that's the current practice :) It's also the easiest one.
Until we have Git, there were no better way. This does not means that we
should not improve our practice. By the way, it was not my thread, if
Thomas has asked, it means that the current practice was not so current.
>
> > Statistics is really less valuable IMO, it is a small interest compare
to
> > code history, that I have use a lot, especially when I have join the
> > project and follow sparingly.
>
> I can say exactly the same thing as you said above. It's just a question
of tools since the history is not lost. It's still there in our active
repos.
There is absolutely no link between these histories. It is not only a
question of tools. Moreover, requiring querying all active repositories to
have a proper history completely defeat the purpose of having separate
repositories.
I do not see the comparison with my remark above. Git has been made for
versionning, not for statistics, it is not my fault.
>
> > So the general rule for me is: Copy history when the source repository
is
> >> removed/deleted/not used anymore.
>
> How many times have you done this? I believe 0 times since I don't think
you'd be so much in favor if you had tried it. I suggest you try it a few
times on your own projects first :) It's really hard to do it right and
very time consuming.
When I have copied the security component from contrib, I have done so. I
hope that I am not alone. And, frankly, it was not so hard, compare to the
advantage you have.
>
> > You never know what will happen to a repository in the future, so this
> > rules is somewhat a hope on the future, no more. And remembering that we
> > may loose history if we do some change in the old repository, is for me
> > like hoping you will remember my birthday ;)
>
> I don't agree with this at all. Again we're not loosing history. If a
repo is removed then its history is copied I agree about that.
I would like to know how you do that after the facts?
>
> >>> Eduard was proposing to include in the first commit of the new
> >>> repository the id of the last commit containing the files (basically
> >>> the id of the parent of the commit deleting the files) in the old
> >>> repository so that it's easier to find it. I'm +1 for this.
> >>
> >
> > But you loose all the benefits of the IDE tools that brings history of a
> > selection automatically and that are really useful.
>
> A huge majority of xwiki's history is already lost to IDEs (when we moved
from SVN) even though the SVN history was moved. Even Git itself doesn't
follow the history when you move stuff around. Said differently it's alwasy
possible to find the history but the IDE and "standard" tool don't follow
it.
It does so far better since we move to Git and it is really a valuable
tool. Do you means that because in a few case, the history may be broken,
that we should not try to have it as complete as possible?
>
> > Moreover, if the history is rewritten due to a change in structure
later,
> > the hash may be broken.
>
> Not sure I understand this one.
In Git, nothing is fully permanent, that is all I say.
>
> You should really measure the cost of what you propose Denis. It's really
hard to do.
Prove me that is more cost than the one newcommers has to enter the
project. Maybe you do not value history so much because you have by your
own experience of the project a good knowledge of what happen in the past.
When I dig in some code, I always found history valuable to understand why
that piece of code is not written the way I may have expected and why I
should not got that way.
If Thomas conclude it is too hard to be done, and not just some developer's
lazyness, I would understand; but I do not agree that it should not be done
just because it breaks statistics or we think it is too hard. This is why I
suggest a tools that do it once for all. I would be really disappointed of
Git if we had to conclude this.
Thanks,
Denis
>
> Thanks
> -Vincent
>
> > So having a broken history is hardening the task of those who want to
> > participate. A great value compare to the statistics IMO.
> >
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > eGuilde sarl - CTO
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
This is an official call for sessions for a "Community development and
Marketing" devroom, hosted at FOSDEM 2013 on Saturday, February 2nd.
In this devroom, developers with different profiles and backgrounds
are invited to brainstorm about aspects related to software projects
which are beyond the code itself, but nevertheless crucial for keeping
the project alive, such as marketing strategies useful for attracting
users and contributors, processes for managing the dynamics of the
community, and open source solutions for project lifecycle management.
While Marketing and FLOSS have long been considered incompatible
concepts, recent history has shown that marketing strategies properly
tailored for the FLOSS world can be of real help for open source
projects without tainting their ideology. Good marketing can be an
essential instrument for reaching out and expanding the community of
users and contributors. You are invited to showcase best practices and
successful collaborations between marketers and developers, to discuss
marketing in a typical hacker environment, and to participate in
establishing a link between communities and in creating opportunities
for collaboration.
Furthermore, you are invited to exchange ideas about what works for
keeping a community in shape: how to encourage contributions from new
members, how to keep people motivated, how to work across time zones
and cultures, how to handle conflicts, what are the processes for
naming new committers or for accepting patches. Presenters can talk
about their favorite combination of tools for version control, code
review, continuous integration, issue tracking, documentation, as well
as full infrastructure setup scenarios. It will be a great environment
for learning from individual success stories about new ways of working
better inside an open source community.
If you are interested in holding a session, please submit your talk
proposal no later than 23-12-2012 (UTC) by sending an email message to
cdm-devroom(a)lists.fosdem.org, and providing the following information:
About the speaker:
- Name
- Affiliation (if any)
- Short bio
About the proposed session:
- Title
- Abstract (no more than 300 words)
- Preferred duration (5, 15 or 30 minutes) and time slot (optional)
You can also subscribe to the mailing list to discuss the devroom
topics with the two organizers, by sending an empty email message to
cdm-devroom-subscribe(a)lists.fosdem.org.
Looking forward to your contributions,
Italo Vignoli (italo(a)italovignoli.com)
Sergiu Dumitriu (sergiu(a)xwiki.org)