¿Cómo es el performance Accurev?

¿Cómo es el performance en la versión actual (4.7) de Accurev ?

  • hora de pago por 100mb, por GB?
  • hora de comprometerse por # de files o mb?
  • capacidad de respuesta de la interfaz gráfica de usuario cuando más de 100 secuencias?

Acabo de tener una demostración de Accurev, y las transmisiones se ven como una forma ligera de modelar el flujo de trabajo alnetworkingedor de código / proyectos. Escuché a personas elogiando a Accurev por las transmisiones de background y quejándose del performance. Accurev parece haber trabajado en el performance, pero me gustaría get algunos datos del mundo real para asegurarme de que no se trate de demos, bueno, funciona less bien.

¿Alguien tiene anécdotas de performance Accurev o (incluso mejor) datos de las testings?

No tengo ningún número pero puedo decirte dónde hemos notado los problemas de performance.

Nuestras comstackciones generalmente usan files de 30-40K del control de fuente. Actualmente, en mi espacio de trabajo hay más de 66K files, incluidos los files intermedios y de salida, de más de 15 GB. Para mantener el funcionamiento correcto de AccuRev, utilizamos los elementos de ignorar de manera agresiva para que AccuRev ignore cualquier file intermedio como * .obj. Además, utilizamos la optimization del sello de time . En general, ejecutar una actualización es rápido, pero el tamaño del proyecto suele ser de 5 a 10 personas, por lo que normalmente solo descienden un par de docenas de files si actualiza diariamente. Incluso si alguien hizo cambios que tocaron muchos files, la velocidad no es un problema. Por otro lado, un llenado completo de todos los 30K + files es lento. No tengo time, ya que rara vez hago esto y en la rara ocasión que lo hago, corro la población cuando voy a almorzar o a una reunión. Supongo que podría ser tanto como 10 minutos. En general, los files de origen descienden muy rápido, pero tenemos algunos files binarys grandes, 10-20MB, que demoran un par de segundos cada uno.

Si las reglas de exclusión y los elementos de ignorar no están configurados correctamente, AccuRev puede tardar unos minutos en ejecutar una actualización para espacios de trabajo de este tamaño. Cuando me integer de que otros desarrolladores se quejan de la velocidad, sé que algo está mal configurado y lo solucionamos.

Hace aproximadamente un año, uno de los proyectos actualizó el impulso con files de 25K + y también agregó FireFox al repository (se olvidó del tamaño pero hizo que el impulso parezca pequeño). También agregaron ICU, escribieron una gran cantidad de software y modificaron innumerables files. En total recuerdo que había aproximadamente 250K + files sentados en una secuencia. Lamentablemente, decidí que todos sus buenos códigos deberían promoverse a la raíz para que todos los proyectos pudieran compartirlos. Esto resultó ser un poco más allá de lo que AccuRev podía manejar bien. Fue un process de varias horas para promocionar todos los cambios. Como recuerdo, una vez que se promocionó Firefox, el rest se desarrolló sin problemas, tal vez una sola transacción con más de 100 mil files fue el problema.

Recientemente actualicé boost y tuve que mantener y promocionar files de 25K +. Tardó uno o dos minutos, pero no es irrazonable teniendo en count la cantidad de files y el tamaño de los files binarys.

En cuanto a la cantidad de transmisiones, tenemos más de 800 transmisiones y espacios de trabajo. El performance aquí no es un problema. En general, me resulta difícil navegar por la gran cantidad de secuencias, por lo que ejecuto una vista filtrada de solo mis espacios de trabajo y las secuencias correctas que me interesan. Sin embargo, cuando necesito ver la list no filtrada para encontrar algo, el performance está bien.

Como nota final, el soporte de AccuRev es excelente : los llamamos la voz en el cielo. De vez en cuando nos disparamos en el pie usando AccuRev y terminamos sin idea de cómo arreglar las cosas. Casi siempre hicimos algo tonto y luego intentamos algo más tonto para arreglarlo. Eventualmente colocamos una request de soporte y lo siguiente que sabemos es que nos guían a través de los pasos hacia la rectitud, ya sea por teléfono o una reunión goto. Incluso los contacté por cosas triviales que simplemente no tengo time para descubrir ya que estoy teniendo un día agitado y amablemente me guiaron en lugar de decirme a RTFM.

Edición 2014: ahora podemos get un performance aceptable de X-Windows utilizando la versión comercial de RealVNC.

Comentario original: esta respuesta se aplica a cualquier versión de Accurev, no solo a 4.7. En primer lugar, el performance de la GUI podría estar bien si puede usar el cliente web. Si no puede usar el cliente web y desea el performance de la GUI, será mejor que use Windows o que todos sus desarrolladores estén en un solo lugar, es decir, donde se encuentra el server de Accurev. ¿Intenta ejecutar la GUI en X-Windows a través de una WAN? Olvídalo: nuestra experiencia ha sido de decenas de segundos o minutos para operaciones básicas de apuntar y hacer clic. Esto es a través de una WAN bastante buena a unas 800 millas de distancia, con un time de ping casi óptimo. Esto no es un fallo de Accurev, sino de X-Windows, y es probable que tenga problemas similares con otras aplicaciones X a través de una WAN. Así que evita la X básica si puedes. Actualmente no podemos, y nuestros usuarios WAN son relegados por la fuerza a la command-line solamente. El problema básico es que Accurev está centralizado y no puede boost la velocidad de la luz. Creo que puede evitar la latencia WAN ejecutando Accurev Replication Servers, pero eso aún no soluciona el problema adecuadamente si tiene desarrolladores remotos en oficinas de una sola persona a través de VPN. Es irónico que los serveres de replicación de alguna manera conviertan este VCS centralizado en una forma de DVCS. Si no tiene serveres de replicación, un trabajo horrible pero algo viable es usar una herramienta de synchronization delta como rsync para sincronizar su tree fuente entre su máquina local donde puede ejecutar la GUI (es decir, la GUI ejecutándose directamente en su Portátil con Windows o Linux) y la máquina en la que realmente está trabajando (p. Ej., La máquina UNIX a 1.000 millas de distancia). Otra opción es usar algo como VNC, que funciona mejor en una WAN que X, conectarse a un escritorio virtual en la location del server Accurev y usar X desde allí. En mi lugar de trabajo, más de un equipo ha recurrido a utilizar Mercurial por un lado y promocionar a Accurev solo cuando es estrictamente necesario. Como señala Stephen Nutt más arriba, otro trabajo necesario es utilizar la optimization del sello de time e ignorarlo. También tenemos nuestros administradores de Accurev (sí, requiere que emplee a personas para cuidarlo) se quejan cuando necesitamos include un gran número de files, a pesar de que forman una parte central de nuestro producto y DEBEN includese y controlarse las versiones. Saca tus propias conclusiones.