Une nouvelle version du portail de gestion des comptes externes sera mise en production lundi 09 août. Elle permettra d'allonger la validité d'un compte externe jusqu'à 3 ans. Pour plus de détails sur cette version consulter : https://doc-si.inria.fr/x/FCeS

Commit 4e08f299 authored by Laurent Tardif's avatar Laurent Tardif
Browse files

This commit was manufactured by cvs2svn to create tag 'v1-0-7'.

parent aac62107
# The "checkoutlist" file is used to support additional version controlled
# administrative files in $CVSROOT/CVSROOT, such as template files.
#
# The first entry on a line is a filename which will be checked out from
# the corresponding RCS file in the $CVSROOT/CVSROOT directory.
# The remainder of the line is an error message to use if the file cannot
# be checked out.
#
# File format:
#
# [<whitespace>]<filename>[<whitespace><error message>]<end-of-line>
#
# comment lines begin with '#'
# The "commitinfo" file is used to control pre-commit checks.
# The filter on the right is invoked with the repository and a list
# of files to check. A non-zero exit of the filter program will
# cause the commit to be aborted.
#
# The first entry on a line is a regular expression which is tested
# against the directory that the change is being committed to, relative
# to the $CVSROOT. For the first match that is found, then the remainder
# of the line is the name of the filter to run.
#
# Format strings present in the filter will be replaced as follows:
# %p = path relative to repository
# %r = repository (path portion of $CVSROOT)
# %{s} = file name, file name, ...
#
# If no format strings are present in the filter string, a default of
# " %r %s" will be appended to the filter string, but this usage is
# deprecated.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name "ALL" appears as a regular expression it is always used
# in addition to the first matching regex or "DEFAULT".
# Set this to "no" if pserver shouldn't check system users/passwords
#SystemAuth=no
# Put CVS lock files in this directory rather than directly in the repository.
#LockDir=/var/lock/cvs
# Set `TopLevelAdmin' to `yes' to create a CVS directory at the top
# level of the new working directory when using the `cvs checkout'
# command.
#TopLevelAdmin=no
# Set `LogHistory' to `all' or `TOEFWUPCGMAR' to log all transactions to the
# history file, or a subset as needed (ie `TMAR' logs all write operations)
#LogHistory=TOEFWUPCGMAR
# Set `RereadLogAfterVerify' to `always' (the default) to allow the verifymsg
# script to change the log message. Set it to `stat' to force CVS to verify
# that the file has changed before reading it (this can take up to an extra
# second per directory being committed, so it is not recommended for large
# repositories. Set it to `never' (the previous CVS behavior) to prevent
# verifymsg scripts from changing the log message.
#RereadLogAfterVerify=always
# Set `UserAdminOptions' to the list of `cvs admin' commands (options)
# that users not in the `cvsadmin' group are allowed to run. This
# defaults to `k', or only allowing the changing of the default
# keyword expansion mode for files for users not in the `cvsadmin' group.
# This value is ignored if the `cvsadmin' group does not exist.
#
# The following string would enable all `cvs admin' commands for all
# users:
#UserAdminOptions=aAbceIklLmnNostuU
# Set `UseNewInfoFmtStrings' to `no' if you must support a legacy system by
# enabling the deprecated old style info file command line format strings.
# Be warned that these strings could be disabled in any new version of CVS.
UseNewInfoFmtStrings=yes
# This file affects handling of files based on their names.
#
# The -m option specifies whether CVS attempts to merge files.
#
# The -k option specifies keyword expansion (e.g. -kb for binary).
#
# Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or .cvswrappers)
#
# wildcard [option value][option value]...
#
# where option is one of
# -f from cvs filter value: path to filter
# -t to cvs filter value: path to filter
# -m update methodology value: MERGE or COPY
# -k expansion mode value: b, o, kkv, &c
#
# and value is a single-quote delimited value.
# For example:
#*.gif -k 'b'
# The "loginfo" file controls where "cvs commit" log information
# is sent. The first entry on a line is a regular expression which must match
# the directory that the change is being made to, relative to the
# $CVSROOT. If a match is found, then the remainder of the line is a filter
# program that should expect log information on its standard input.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name ALL appears as a regular expression it is always used
# in addition to the first matching regex or DEFAULT.
#
# If any format strings are present in the filter, they will be replaced as follows:
# %p = path relative to repository
# %r = repository (path portion of $CVSROOT)
# %{sVv} = attribute list = file name, old version number (pre-checkin),
# new version number (post-checkin). When either old or new revision is
# unknown, doesn't exist, or isn't applicable, the string "NONE" will be
# placed on the command line instead.
#
# Note that %{sVv} is a list operator and not all elements are necessary. Thus %{sv} is
# a legal format string, but will only be replaced with file name and new revision.
# it also generates multiple arguments for each file being operated upon. i.e. if two
# files, file1 & file2, are being commited from 1.1 to version 1.1.2.1 and from 1.1.2.2
# to 1.1.2.3, respectively, %{sVv} will generate the following six arguments in this
# order: file1, 1.1, 1.1.2.1, file2, 1.1.2.2, 1.1.2.3.
#
# For example:
#DEFAULT (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commitlog
# or
#DEFAULT (echo ""; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog
DEFAULT /usr/bin/syncmail -f users.gforge.inria.fr %S transmorpher-commits@lists.gforge.inria.fr
^transmorpher (date; cat; (sleep 2; cd /home/groups/transmorpher/htdocs ; cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
# Three different line formats are valid:
# key -a aliases...
# key [options] directory
# key [options] directory files...
#
# Where "options" are composed of:
# -i prog Run "prog" on "cvs commit" from top-level of module.
# -o prog Run "prog" on "cvs checkout" of module.
# -e prog Run "prog" on "cvs export" of module.
# -t prog Run "prog" on "cvs rtag" of module.
# -u prog Run "prog" on "cvs update" of module.
# -d dir Place module in directory "dir" instead of module name.
# -l Top-level directory only -- do not recurse.
#
# NOTE: If you change any of the "Run" options above, you'll have to
# release and re-checkout any working directories of these modules.
#
# And "directory" is a path to a directory relative to $CVSROOT.
#
# The "-a" option specifies an alias. An alias is interpreted as if
# everything on the right of the "-a" had been typed on the command line.
#
# You can encode a module within a module by using the special '&'
# character to interpose another module into the current module. This
# can be useful for creating a module that consists of many directories
# spread out over the entire source repository.
# The "notify" file controls where notifications from watches set by
# "cvs watch add" or "cvs edit" are sent. The first entry on a line is
# a regular expression which is tested against the directory that the
# change is being made to, relative to the $CVSROOT. If it matches,
# then the remainder of the line is a filter program that should contain
# one occurrence of %s for the user to notify, and information on its
# standard input.
#
# "ALL" or "DEFAULT" can be used in place of the regular expression.
#
# format strings are replaceed as follows:
# %p = path relative to repository
# %r = repository (path portion of $CVSROOT)
# %s = user to notify
#
# For example:
#ALL (echo Committed to %r/%p; cat) |mail %s -s "CVS notification"
# The "rcsinfo" file is used to control templates with which the editor
# is invoked on commit and import.
#
# The first entry on a line is a regular expression which is tested
# against the directory that the change is being made to, relative to the
# $CVSROOT. For the first match that is found, then the remainder of the
# line is the name of the file that contains the template.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name "ALL" appears as a regular expression it is always used
# in addition to the first matching regex or "DEFAULT".
# The "taginfo" file is used to control pre-tag checks.
# The filter on the right is invoked with the following arguments if no format strings are present:
#
# $1 -- tagname
# $2 -- operation "add" for tag, "mov" for tag -F, and "del" for tag -d
# $3 -- tagtype "?" on delete, "T" for branch, "N" for static
# $4 -- repository
# $5-> file revision [file revision ...]
#
# If any format strings are present in the filter, they will be replaced as follows:
# %b = branch mode = "?" (delete ops - unknown) | "T" (branch) | "N" (not branch)
# %o = operation = "add" | "mov" | "del"
# %p = path relative to repository
# %r = repository (path portion of $CVSROOT)
# %t = tagname
# %{sVv} = attribute list = file name, old version tag will be deleted from,
# new version tag will be added to (or deleted from, but this feature is
# deprecated. When either old or new revision is unknown, doesn't exist,
# or isn't applicable, the string "NONE" will be placed on the command
# line.
#
# Note that %{sVv} is a list operator and not all elements are necessary. Thus %{sV} is
# a legal format string, but will only be replaced with file name and old revision.
# it also generates multiple arguments for each file being operated upon. i.e. if two
# files, file1 & file2, are having a tag moved from version 1.1 to versoin 1.1.2.9, %{sVv}
# will generate the following six arguments in this order: file1, 1.1, 1.1.2.9, file2, 1.1,
# 1.1.2.9.
#
# A non-zero exit of the filter program will cause the tag to be aborted.
#
# The first entry on a line is a regular expression which is tested
# against the directory that the change is being committed to, relative
# to the $CVSROOT. For the first match that is found, then the remainder
# of the line is the name of the filter to run.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name "ALL" appears as a regular expression it is always used
# in addition to the first matching regex or "DEFAULT".
# The "verifymsg" file is used to allow verification of logging
# information. It works best when a template (as specified in the
# rcsinfo file) is provided for the logging procedure. Given a
# template with locations for, a bug-id number, a list of people who
# reviewed the code before it can be checked in, and an external
# process to catalog the differences that were code reviewed, the
# following test can be applied to the code:
#
# Making sure that the entered bug-id number is correct.
# Validating that the code that was reviewed is indeed the code being
# checked in (using the bug-id number or a seperate review
# number to identify this particular code set.).
#
# If any of the above test failed, then the commit would be aborted.
#
# Format strings present in the filter will be replaced as follows:
# %p = path relative to repository
# %r = repository (path portion of $CVSROOT)
# %l = name of log file to be verified.
#
# If no format strings are present in the filter, a default " %l" will
# be appended to the filter, but this usage is deprecated.
#
# Actions such as mailing a copy of the report to each reviewer are
# better handled by an entry in the loginfo file.
#
# One thing that should be noted is the the ALL keyword is not
# supported. There can be only one entry that matches a given
# repository.
#---No Comment---
#Sun Sep 08 16:39:15 CEST 2002
directory=/local_home/gchomat/flowcomposer/test/process
accelbarOrientation=0
toolbarOrientation=1
This diff is collapsed.
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"/home/ferio/gchomat/dbkDTD/docbookx.dtd">
<article>
<title>Carnet de bords</title>
<subtitle>FlowComposer</subtitle>
<articleinfo>
<authorgroup>
<author>
<firstname>Guillaume</firstname>
<surname>Chomat</surname>
</author>
<author>
<firstname>Frédéric</firstname>
<surname>Saint-Marcel</surname>
</author>
</authorgroup>
</articleinfo>
<section><title>03-04-2002</title>
<para>Etude de faisabilité d'utilisation de JGraph : utiliser JGraph comme composant swing au sein du Flowcomposer.</para>
</section>
<section><title>05-04-2002</title>
<section>
<title>Observer/Observable</title>
<para>L'idée principale derière Observers et observables est qu'un objet observable a une méthode que un observer appelle afin d'enregistrer ses intérêts. Quand un changement se produit, l'objet observable envoie une notification en appelant une méthode dans chaque observers.</para>
</section>
<section>
<title>Etude de la connection entre JGraph et Transmorpher</title>
<para>Une première approche consiste à ce que tous les objets du transmorpher graph soit des Observables et tous les objets de JGraph soit des Observers sur ces derniers.</para>
<para>De ce fait toute modification effectué sur le transmorpher graph sera répercuté sur le JGraph servant à l'affichage.</para>
<para>L'indépendance entre Flowcomposer et Transmorpher sera de ce fait plus forte.</para>
<para>De plus, la connection entre Flowcomposer et d'autres outils se basant sur Transmorpher sera plus aisée.</para>
</section>
<section>
<title>Debut d'une première maquette basée sur JGraph</title>
<para>Afin de mieux cerner JGraph et son principe de fonctionnement, la décision d'établir une première maquette du Flowcomposer a été prise.</para>
<para>Cette première maquette en est à ce jour en un stade peu avancée. Les différents éléments propre à notre JGraph ont été implémentés(..Cell,...Renderer,..View). Enfin des problèmes de compréhension sur le principe de fonctionnements des actions en swing ont été rencontrés.</para>
</section>
</section>
<section>
<title>08-04-2002</title>
<para>Mise en place de la maquette suite. Necessité de comprendre plus en profondeur JGraph afin de l'appliquer à nos contraintes de graph</para>
</section>
<section>
<title>09-04-2002</title>
<para>Mise en place de la maquette suite. Necessité de comprendre plus en profondeur JGraph afin de l'appliquer à nos contraintes de graph</para>
<para>Dans le modèle de JGraph les ports sont définis par défaut. Pour Flowcomposer, il faudra les déterminer et les créer dynamiquement. De plus la connection entre les composants se fera de la manière suivante:
L'utilisateur selectionnera le composant dont l'output l'intéresse en maintenant la bouton appuyé il se placera sur le composant dont l'input l'intéresse il relachera alors la souris et la connection sera crée entre un output du premier et l'input du deuxième
</para>
</section>
<section>
<title>10-04-2002</title>
<para>En fin de journée, on avait une première ébauche d'application avec JGraph.</para>
</section>
<section>
<title>11-04-2002</title>
<para>Implémentation du prototype version 0.1 suite.</para>
<itemizedlist>
<listitem>
<para>UndoManager</para>
</listitem>
<listitem>
<para>Connection entre composant</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>12-04-2002</title>
<para>Implémentation du prototype version 0.1 suite.</para>
<itemizedlist>
<listitem>
<para>création du menu</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>15-04-2002</title>
<para>Implémentation du prototype version 0.1 suite.</para>
<itemizedlist>
<listitem>
<para>définition de toutes les actions du menu.</para>
</listitem>
<listitem>
<para>Recherche de solution pour générer un jar contenant les répertoires suivants :</para>
<simplelist>
<member>fr/ : Classes du projet.</member>
<member>resources/ : Toutes les resources necessaires au FlowComposer. Réfléchir à les sortir du jar.</member>
<member>META-INF/MANIFEST.MF</member>
</simplelist>
<para>jgraph.jar ne doit pas se trouver dans le jar</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>16-04-2002</title>
<para>Préparation de la soutenance mi-parcours.</para>
<para>Premier contact avec l'audit : présentation du projet</para>
<para>Solution trouvée pour la génération du jar.Mise à jour de la base CVS.</para>
</section>
<section>
<title>17-04-2002</title>
<para>Préparation de la soutenance de mi-parcours suite.</para>
</section>
<section>
<title>18-04-2002</title>
<para>Préparation de la soutenance de mi-parcours suite.</para>
<para>Mise à jour du cdc en vue du première audit</para>
</section>
<section>
<title>19-04-2002</title>
<para>Mis à jour de la documentation en vue du premier audit le 27 avril 2002.</para>
<para>Ajout de la documentation du projet dans la base CVS.</para>
<para>Ajout, dans la base CVS, des fichiers necessaires à la générations des formats HTML de la documentation</para>
<para>Possibilité de générer la documentation HTML en exécutant la commande suivante dans le répertoire lib : java -jar transmo.jar docbook.xml</para>
<para>Continuation de la préparation de la soutenance mi-parcours</para>
</section>
<section>
<title>Semaine du 22-04-2002</title>
<itemizedlist>
<listitem>
<para>Définition et rédaction des Spécifications Externes.</para>
</listitem>
<listitem>
<para>Validation de l'utilisation de JGraph</para>
<para>Implémentation des spécifications externes.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 29-04-2002</title>
<itemizedlist>
<listitem>
<para>Conception et implémentation de la construction du graph Transmorpher.</para>
</listitem>
<listitem>
<para>Tests de la construction</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 06-05-2002</title>
<itemizedlist>
<listitem>
<para>Conception et implémentation de l'ouvertue d'un document XML respectant la DTD Transmorpher.</para>
</listitem>
<listitem>
<para>Tests de l'ouvertue de documents XML.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Période du 13-05-2002 au 24-05-2002</title>
<itemizedlist>
<listitem>
<para>Conception et implémentation de la sauvegarde des compositions éditées.</para>
</listitem>
<listitem>
<para>Tests</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>semaine du 27-05-2002</title>
<itemizedlist>
<listitem>
<para>Conception et implémentation de l'exécution d'une composition.</para>
</listitem>
<listitem>
<para>Tests</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Période du 03-06-2002 au 14-06-2002</title>
<itemizedlist>
<listitem>
<para>Conception et implémentation de la compilation d'une composition.</para>
</listitem>
<listitem>
<para>Tests</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>semaine du 17-06-2002</title>
<itemizedlist>
<listitem>
<para>Mis à jour des documents.</para>
</listitem>
<listitem>
<para>Préparation du deuxième audit.</para>
</listitem>
<listitem>
<para>Etablis les jeux de test.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 24-06-2002</title>
<itemizedlist>
<listitem>
<para>Test du prototype 0.1.</para>
</listitem>
<listitem>
<para>Validation du prototype 0.1</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 01-07-2002</title>
<itemizedlist>
<listitem>
<para>Définition et impléméntation d'un plan de travail pour l'édition de process</para>
</listitem>
<listitem>
<para>Tests sur l'implémentation d'un plan de travail</para>
</listitem>
<listitem>
<para>Modifier le Panel des properties pour être conforme au spécificitées de Transmorpher</para>
</listitem>
<listitem>
<para>Etablir des jeux de test et tester le nouveau panel properties</para>
</listitem>
<listitem>
<para>Implémenter la suppression des composants suivant le model Observer/Observable</para>
</listitem>
<listitem>
<para>Etablir des jeux de test pour la suppression.</para>
</listitem>
<listitem>
<para>Appliquer les jeux de test.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 08-07-2002</title>
<itemizedlist>
<listitem>
<para>Définition et implémentation d'un algorithme de layourt basic.</para>
</listitem>
<listitem>
<para>Etablir des jeux de test et Tester l'algorithme.</para>
</listitem>
<listitem>
<para>Définition et implémentation de la fenêtre "About".</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 22-07-2002</title>
<para>Abscence de Guillaume toute la semaine: cause de son mariage</para>
<itemizedlist>
<listitem>
<para>Amélioration de l'algorithme de layout Basic.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 29-07-2002</title>
<para>Abscence de Guillaume lundi et mardi</para>
<itemizedlist>
<listitem>
<para>Plan de test</para>
</listitem>
<listitem>
<para>Tests et correction des bugs éventuels</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 05-08-2002</title>
<itemizedlist>
<listitem>
<para>Préparation du 3 éme audit</para>
<para>Rédiger Manuel Utilisateur</para>
<para>Réviser tous les autres documents</para>
</listitem>
<listitem>
<para>ApplyProcess/Process</para>
<para>Modification/ajout/suppression de ports.</para>
</listitem>
<listitem>
<para>Suppression de process</para>
</listitem>
<listitem>
<para>Suppression de ports</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 12-08-2002</title>
<itemizedlist>
<listitem>
<para>Conception et implémentation d'un algorithme de détection de cycle.</para>
</listitem>
<listitem>
<para>Conception et implémentation d'une console gérant les erreurs emise par Transmorpher.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 19-08-2002</title>
<itemizedlist>
<listitem>
<para>Test du prototype 0.2</para>
</listitem>
<listitem>
<para>Validation du prototype 0.2</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Semaine du 25-08-2002</title>
<itemizedlist>
<listitem>
<para>Préparation de la soutenance.</para>
</listitem>
<listitem>
<para>Mis en place de la démo.</para>
</listitem>
</itemizedlist>
</section>
</article>
\ No newline at end of file
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"/home/ferio/gchomat/dbkDTD/docbookx.dtd">