Problemas de Bazaar por solucionar

Bazaar (bzr) es un sistema de control de versiones (para lo mismo que CVS, Subversion, git, …). Es de licencia libre (es parte de GNU) y se centra en usabilidad, pero aún le falta. Como le he ido encontrando muchos fallos (más de los que me gustaría), estoy intentando corregirlos. Aquí pongo una lista y mi progreso. En 2017 esta página importa poco pues bazaar está muy parado (aunque me sigue gustando más que git/mercurial).

Esta página es parte de mi lista de cosas por hacer e incluye muchas notas personales e información irrelevante o anticuada. Se puede ver de forma estructurada con org-mode (es como mantengo ésta y otras listas de tareas; lo explico aquí).

26.m10.2017 (desde 2009). Daniel Clemente Laboreo (web, correo). Este fichero .html se ve mejor abriendo el .org con org-mode (Emacs)

Otras listas: Índice (varias tareas) Temas de investigación (tareas mayores) Emacs Bazaar Conkeror Sobre este sistema (y org-mode)


Índice


1 bazaar, problemas básicos

1.1 lista de varios fallos que he informado, y enlace a lista completa

Están por aquí: https://bugs.launchpad.net/~n142857

Los que yo mandé están en: https://bugs.launchpad.net/~n142857/+reportedbugs

Algunos de ellos:

1.2 IS Primera contribución: documentación

1.2.1 notas que tomé sobre cómo hice la contribución

Pues lo hice en una rama, luego hice „bundle“ y envié el .patch en un correo con asunto „[MERGE]“. Al cabo de mucho tiempo (el 19-9-2008) 2 personas aprobaron mi tercera revisión y lo incluyeron en la rama oficial (para la siguiente a la bzr 1.7rc2, creo, pero no sé cuál será). Mi cambio fue la revisión 3712. Me salió con todos mis envíos (5, muy separados en el tiempo) y se vio qué versión cogí como base (era una antigua, la 3651).

http://bundlebuggy.aaronbentley.com/project/bzr/request/<877i9roh2j.fsf@gmail.com>

Le añadieron documentación (el título de mi correo + mi nombre) al fichero NEWS. Mezclaron mi cambio en una rama, y luego ésa en otra (¿en „trunk“?). Después vi mi cambio en el bzr oficial :-) Mi primer parche a Bazaar.

Salió en el registro de bzr 1.8:

DOCUMENTATION:
  * Explain revision/range identifiers. (Daniel Clemente)

1.3 uno de usabilidad

1.4 fallos de Unicode (vistos durante la migración git→bzr)

1.4.1 IS error 230996; algunas notas

Creo que está en fastimport y no en bzr-git. No estoy seguro.

1.4.1.1 Reproducir error

7.6.2008

mkdir dos
cd dos
git init
echo més >prova
file prova # Check it's utf-8
iconv -f utf-8 -t iso-8859-1 prova >prova.8859
git add prova prova.8859
git commit -a -m inici
git-fast-export --all >expo
iconv -f utf-8 -t utf-8 expo >/dev/null # Will show you an error
1.4.1.2 Veredicto

Según #git no es fallo de git-fast-export pues vuelca todo en crudo. Mezcla por tanto codificaciones. Los importadores deberían tener todo esto en cuenta.

En bzr:

Solución final:

  • probar con bzr>1.5

1.4.2 IS fallo 272444 (support symlinks to non-ascii targets)

  • CONCLUSIÓN escrita el <12.m03.2009 10:46>
    Exactamente medio año después (hoy se cumple), está arreglado

Veo:

inv_entry.symlink_target  

es de tipo:

<type 'unicode'>

Y mientras que str("aŝ") va, str(u"aŝ") no. ¿Qué hace str?

Importante:

  • "aŝ" es de tipo str. Pero u"aŝ" es de tipo unicode
1.4.2.1 Mis primeros esfuerzos (horarios) para descubrir qué falla

Esto ya está mal:

self._dirblocks[1]
('', [(('', 'prova', 'prova-20081011104329-9z25aw23tznwvfnp-1'), [('a', '', 0, False, ''), ('l', u'm\xe9s'0, False, 'dcl441-bugs@yahoo.com-20081011104330-aoma828b7t0x1kap')])])
(Pdb) self._dirblocks[1]

p self._dirblocks[1][1][0][1][1][1]
u'm\xe9s'

(Pdb) self._dirblocks[1][1][0][1][1][1].encode("utf-8")
'm\xc3\xa9s'

Ya se llama, con esto mal puesto, a: def _entries_to_current_state(self, new_entries): ¿Quién lo llama?

  /w/bzr/bug_272444/bzr(130)<module>()
-> exit_val = bzrlib.commands.main(sys.argv)
  /Werkstatt/bzr/bug_272444/bzrlib/commands.py(840)main()
-> ret = run_bzr_catch_errors(argv)
  /Werkstatt/bzr/bug_272444/bzrlib/commands.py(849)run_bzr_catch_errors()
-> return run_bzr(argv)
  /Werkstatt/bzr/bug_272444/bzrlib/commands.py(795)run_bzr()
-> ret = run(*run_argv)
  /Werkstatt/bzr/bug_272444/bzrlib/commands.py(495)run_argv_aliases()
-> return self.run(**all_cmd_args)
  /Werkstatt/bzr/bug_272444/bzrlib/builtins.py(980)run()
-> force_new_repo=standalone)
  /Werkstatt/bzr/bug_272444/bzrlib/bzrdir.py(1137)sprout()
-> hardlink=hardlink)
  /Werkstatt/bzr/bug_272444/bzrlib/bzrdir.py(1451)create_workingtree()
-> accelerator_tree=accelerator_tree, hardlink=hardlink)
  /Werkstatt/bzr/bug_272444/bzrlib/workingtree_4.py(1387)initialize()
-> wt.set_parent_trees(parents_list, allow_leftmost_as_ghost=True)
  /Werkstatt/bzr/bug_272444/bzrlib/mutabletree.py(52)tree_write_locked()
-> return unbound(self, *args, **kwargs)
  /Werkstatt/bzr/bug_272444/bzrlib/workingtree_4.py(1127)set_parent_trees()
-> dirstate.set_parent_trees(real_trees, ghosts=ghosts)
  /Werkstatt/bzr/bug_272444/bzrlib/dirstate.py(2290)set_parent_trees()
-> self._entries_to_current_state(new_entries)
> /Werkstatt/bzr/bug_272444/bzrlib/dirstate.py(1026)_entries_to_current_state()
-> if entry[0][0] != current_dirname:

Al final lo „corrijo“ poniendo sólo:

inv_entry.symlink_target.encode('utf-8') or ''

en vez de llamar a str(…)

Pero sigue fallando… con mi propio test:

Traceback (most recent call last):
  File "/Werkstatt/bzr/bug_24yt5/bzrlib/tests/workingtree_implementations/test_parents.py", line 241, in test_utf8_symlink
    revision = tree.commit('added a link to an utf-8 target')
  File "/Werkstatt/bzr/bug_24yt5/bzrlib/decorators.py", line 192, in write_locked
    result = unbound(self, *args, **kwargs)
  File "/Werkstatt/bzr/bug_24yt5/bzrlib/workingtree_4.py", line 237, in commit
    result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
  File "/Werkstatt/bzr/bug_24yt5/bzrlib/decorators.py", line 192, in write_locked
    result = unbound(self, *args, **kwargs)
  File "/Werkstatt/bzr/bug_24yt5/bzrlib/mutabletree.py", line 197, in commit
    revprops=revprops, *args, **kwargs)
  File "/Werkstatt/bzr/bug_24yt5/bzrlib/commit.py", line 412, in commit
    self._basis_delta)
  File "/Werkstatt/bzr/bug_24yt5/bzrlib/workingtree_4.py", line 1277, in update_basis_by_delta
    self.current_dirstate().update_basis_by_delta(delta, new_revid)
  File "/Werkstatt/bzr/bug_24yt5/bzrlib/dirstate.py", line 1341, in update_basis_by_delta
    inv_to_entry(inv_entry), True))
  File "/Werkstatt/bzr/bug_24yt5/bzrlib/dirstate.py", line 1851, in _inv_entry_to_details
    fingerprint = inv_entry.symlink_target.encode('utf-8') or ''
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128)

----------------------------------------------------------------------
Ran 3 tests in 1.549s

A ver…

1853 ->	            fingerprint = inv_entry.symlink_target.encode('utf-8') or ''                                       

Claro

(Pdb) p inv_entry.symlink_target
'adi\xc3\x83\xc2\xb3s'
(Pdb) p inv_entry.symlink_target.encode('utf-8')
UnicodeDecodeError: UnicodeDecodeError('ascii', 'adi\xc3\x83\xc2\xb3s', 3, 4, 'ordinal not in range(128)')

(Pdb) p delta[0][3].symlink_target
'adi\xc3\x83\xc2\xb3s'


(Pdb) p self._basis_delta
[(None, u'', 'tree_root-20081011184217-sdy2f0k6tpofp1y9-1', InventoryDirectory('tree_root-20081011184217-sdy2f0k6tpofp1y9-1', u'', parent_id=None, revision='dc@ali-20081011184217-8loc0uuq15qgjtoy')), (None, u'link_name', 'link-id', InventoryLink('link-id', u'link_name', parent_id='tree_root-20081011184217-sdy2f0k6tpofp1y9-1', revision='dc@ali-20081011184217-8loc0uuq15qgjtoy'))]
(Pdb) p self._basis_delta[1][3].symlink_target
'adi\xc3\x83\xc2\xb3s'
(Pdb) 

Aquí ya lo está leyendo mal, en el readlink…

714  	        elif kind == 'symlink':
715  ->	            return ('symlink', None, None, os.readlink(abspath))

Problema: creo que no es que no lo lea bien. Es que mi test NO LO ESCRIBE bien.

: ~ ; ll '/tmp/testbzr-UhnsTF.tmp/bzrlib.tests.workingtree_implementations.test_parents.TestSetParents.test_utf8_symlink(WorkingTreeFormat4)/work/tree1/link_name'
lrwxrwxrwx 1 dc dc 8 oct 11 21:07 /tmp/testbzr-UhnsTF.tmp/bzrlib.tests.workingtree_implementations.test_parents.TestSetParents.test_utf8_symlink(WorkingTreeFormat4)/work/tree1/link_name -> adiós

Al menos sé cómo descubrir dónde está mi repo: abspath = self.abspath(path)

1.4.2.2 MALFAR problemilla de diseño: la huella („fingerprint“) es por definición el destino del enblance („symlink“), pero la huella ha de ser unicode, mientras que el destino quizás no lo es
  • CONCLUSIÓN escrita el <16.m02.2009 20:50>
    mentira; fingerprint ha de ser utf8 y ya va bien

Soluciones:

  • sólo permitir enlaces a destino Unicode
  • usar como huella alguna otra cosa (ej: hash)
  • usar una huella sin codificación unicode
1.4.2.3 descubierto: en mi parche, sobre la u en el u'adiós'

Estu os.symlink('adi33s','tree1/link2')

Estaba creando el enlace hacia:

adiós

En vez de hacia:

adiós

1.4.2.3.1 IS reenviar corregido
1.4.2.4 quizás apliqué el cambio incorrecto

Ya en set_parent_trees al principio:

p trees[0][1].inventory['link2-id'].symlink_target
u'adi\xf3s'

Creo que eso no está bien… no por lo del 3 (parece correcto) sino por meter un objeto de tipo unicode (debería ser str). Aunque no entiendo de esto…

En set_parent_ids (de WorkingTree4) se complica…:

(Pdb) p self.branch.repository.revision_tree(revision_ids[0]).inventory['link2-id'].symlink_target

NOTA: en esa línea se ve muy rápido un repaso de muchos conceptos de Bazaar

Al final, ¡llegué al test! Así se ve el destino del enblance:


tree = self.make_branch_and_tree('tree1')                                                                      
#import pdb                                                                                                    
#pdb.set_trace()                                                                                               

os.symlink('adi\xc3\xb3s','tree1/link2')                                                                       
tree.add(['link2'],['link2-id'])                                                                               
revision = tree.commit('added a second link to an utf-8 target')                                               

print "ahora mismo (en el test), el enlace ya está algo mal: ", tree.branch.repository.revision_tree(revision).inventory['link2-id'].symlink_target                                                                                   

#try:                                                                                                          
#    tree.set_parent_ids([revision])                                                                           
tree.set_parent_ids([revision])                                                                                
#except UnicodeEncodeError, e:                                                                                 
#    raise KnownFailure('there is no support for symlinks to non-ASCII targets')                               


Fórmula mágica: tree.branch.repository.revision_tree(revision).inventory['link2-id'].symlink_target

Quizás con tree.inventory también va. Pero no hay que coger el inventory['TREE_ROOT']

Veo que en mutabletree 133 le hace:

self._add(files, ids, kinds)                                                                                   

y ahí se añade al inventario. Pero no le pone el valor:

p self.inventory['link2-id'].symlink_target
None

Y en test justo antes del commit:

(Pdb) p tree.inventory['link2-id'].symlink_target
None

Creo que es el commit el que graba contenido.

Entro en:

826  	            self._record_entry(path, file_id, specific_files, kind, name,
827  ->	                parent_id, definitely_changed, existing_ie, report_changes,
828  	                content_summary)

He encontrado algo muy importante: repository.py, 384


elif kind == 'symlink':                                                                                        
     current_link_target = content_summary[3]                                                                   
     if not store:                                                                                              
         # symlink target is not generic metadata, check if it has                                              
         # changed.                                                                                             
         if current_link_target != parent_entry.symlink_target:                                                 
             store = True                                                                                       
     if not store:                                                                                              
         # unchanged, carry over.                                                                               
         ie.revision = parent_entry.revision                                                                    
         ie.symlink_target = parent_entry.symlink_target                                                        
         return self._get_delta(ie, basis_inv, path), False, None                                               
     ie.symlink_target = current_link_target                                                                    
     lines = []                                                                                                 
     self._add_text_to_weave(ie.file_id, lines, heads, None)                                                    
ie.symlink_target = current_link_target

Bien, ambos de tipo str y con valor 'adi33s'

Me salto esto:

2410 ->	        for key, size in key_sizes:
2411 	            p_offset, p_length = self._container_writer.add_bytes_record(
2412 	                raw_data[offset:offset+size], [])
2413 	            offset += size

Y:

752  	            parents = ()
753  	        return self._add(key, lines, parents,
754  ->	            parent_texts, left_matching_blocks, nostore_sha, random_id)

Me parece que por la zona del 422 de repository.py se ha dado valor (bueno) a ie.symlink_target

A ver cuando empieza a hacer esto…:

875  ->	        if delta:
876  	            self._basis_delta.append(delta)

Pues no, se dev. bien

Quizás en xml8.py, 239, …

243  	                        parent_str, parent_id,
244  	                        _encode_and_escape(ie.revision),
245  	                        _encode_and_escape(ie.symlink_target)))
(Pdb) p ie.symlink_target
'adi\xc3\xb3s'
(Pdb) p _encode_and_escape(ie.symlink_target)
'adi&#243;s"'
(Pdb) 

Bueno… lo graba bien. Quizás si luego lo lee es cuando hay problemas.

Ya he visto que falla bzrlib/dirstate.py(1861)_inv_entry_to_details() al entrar por 2ª vez; en la parte de set_parents_id (creo que la otra, la que se ocupa del commit, va bien).

1.4.2.4.1 MALFAR seguir depurando esta 2ª vez de set_parents_id
  • CONCLUSIÓN escrita el <16.m02.2009 20:49>
    me lié mucho
1.4.2.4.1.1 la primera vuelta
(Pdb) p fingerprint
'adi\xc3\xb3s'
(Pdb) bt
  /tmp/testbzr-YrnJ8d.tmp/bzrlib.tests.workingtree_implementations.test_parents.TestSetParents.test_utf8_symlink(WorkingTreeFormat4)/work/bzr(130)<module>()
-> exit_val = bzrlib.commands.main(sys.argv)
  /Werkstatt/bzr/bug_24yt5/bzrlib/commands.py(840)main()
-> ret = run_bzr_catch_errors(argv)
  /Werkstatt/bzr/bug_24yt5/bzrlib/commands.py(849)run_bzr_catch_errors()
-> return run_bzr(argv)
  /Werkstatt/bzr/bug_24yt5/bzrlib/commands.py(795)run_bzr()
-> ret = run(*run_argv)
  /Werkstatt/bzr/bug_24yt5/bzrlib/commands.py(495)run_argv_aliases()
-> return self.run(**all_cmd_args)
  /Werkstatt/bzr/bug_24yt5/bzrlib/builtins.py(2828)run()
-> starting_with=starting_with,
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/__init__.py(2589)selftest()
-> strict=strict)
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/__init__.py(2529)run_suite()
-> result = runner.run(suite)
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/__init__.py(543)run()
-> test.run(result)
  /usr/lib/python2.5/unittest.py(433)run()
-> test(result)
  /usr/lib/python2.5/unittest.py(281)__ c a l l __()
-> return self.run(*args, **kwds)
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/__init__.py(1293)run()
-> return unittest.TestCase.run(self, result)
  /usr/lib/python2.5/unittest.py(260)run()
-> testMethod()
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/workingtree_implementations/test_parents.py(248)test_utf8_symlink()
-> revision = tree.commit('added a second link to an utf-8 target')
  /Werkstatt/bzr/bug_24yt5/bzrlib/decorators.py(192)write_locked()
-> result = unbound(self, *args, **kwargs)
  /Werkstatt/bzr/bug_24yt5/bzrlib/workingtree_4.py(238)commit()
-> result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
  /Werkstatt/bzr/bug_24yt5/bzrlib/decorators.py(192)write_locked()
-> result = unbound(self, *args, **kwargs)
  /Werkstatt/bzr/bug_24yt5/bzrlib/mutabletree.py(201)commit()
-> revprops=revprops, *args, **kwargs)
  /Werkstatt/bzr/bug_24yt5/bzrlib/commit.py(419)commit()
-> self._basis_delta)
  /Werkstatt/bzr/bug_24yt5/bzrlib/workingtree_4.py(1281)update_basis_by_delta()
-> self.current_dirstate().update_basis_by_delta(delta, new_revid)
  /Werkstatt/bzr/bug_24yt5/bzrlib/dirstate.py(1346)update_basis_by_delta()
-> inv_to_entry(inv_entry), True))
> /Werkstatt/bzr/bug_24yt5/bzrlib/dirstate.py(1862)_inv_entry_to_details()
-> size = 0
1.4.2.4.1.2 la segunda vuelta (fingerprint ya está mal)
(Pdb) p fingerprint
u'adi\xf3s'
(Pdb) bt
  /tmp/testbzr-Q3X6ES.tmp/bzrlib.tests.workingtree_implementations.test_parents.TestSetParents.test_utf8_symlink(WorkingTreeFormat4)/work/bzr(130)<module>()
-> exit_val = bzrlib.commands.main(sys.argv)
  /Werkstatt/bzr/bug_24yt5/bzrlib/commands.py(840)main()
-> ret = run_bzr_catch_errors(argv)
  /Werkstatt/bzr/bug_24yt5/bzrlib/commands.py(849)run_bzr_catch_errors()
-> return run_bzr(argv)
  /Werkstatt/bzr/bug_24yt5/bzrlib/commands.py(795)run_bzr()
-> ret = run(*run_argv)
  /Werkstatt/bzr/bug_24yt5/bzrlib/commands.py(495)run_argv_aliases()
-> return self.run(**all_cmd_args)
  /Werkstatt/bzr/bug_24yt5/bzrlib/builtins.py(2828)run()
-> starting_with=starting_with,
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/__init__.py(2589)selftest()
-> strict=strict)
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/__init__.py(2529)run_suite()
-> result = runner.run(suite)
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/__init__.py(543)run()
-> test.run(result)
  /usr/lib/python2.5/unittest.py(433)run()
-> test(result)
  /usr/lib/python2.5/unittest.py(281)__ c a l l __()
-> return self.run(*args, **kwds)
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/__init__.py(1293)run()
-> return unittest.TestCase.run(self, result)
  /usr/lib/python2.5/unittest.py(260)run()
-> testMethod()
  /Werkstatt/bzr/bug_24yt5/bzrlib/tests/workingtree_implementations/test_parents.py(259)test_utf8_symlink()
-> tree.set_parent_ids([revision])
  /Werkstatt/bzr/bug_24yt5/bzrlib/mutabletree.py(53)tree_write_locked()
-> return unbound(self, *args, **kwargs)
  /Werkstatt/bzr/bug_24yt5/bzrlib/workingtree_4.py(1090)set_parent_ids()
-> allow_leftmost_as_ghost=allow_leftmost_as_ghost)
  /Werkstatt/bzr/bug_24yt5/bzrlib/mutabletree.py(53)tree_write_locked()
-> return unbound(self, *args, **kwargs)
  /Werkstatt/bzr/bug_24yt5/bzrlib/workingtree_4.py(1131)set_parent_trees()
-> dirstate.set_parent_trees(real_trees, ghosts=ghosts)
  /Werkstatt/bzr/bug_24yt5/bzrlib/dirstate.py(2249)set_parent_trees()
-> self._inv_entry_to_details(entry)
> /Werkstatt/bzr/bug_24yt5/bzrlib/dirstate.py(1862)_inv_entry_to_details()
-> size = 0
(Pdb) 
1.4.2.4.1.3 en qué divergen
  • la primera es para la línea revision = tree.commit('added a second link to an utf-8 target')
  • la segunda para la siguiente: tree.set_parent_ids([revision])
  • la primera pasa por: test_parents.py:test_utf8_symlink; decorators.py:write_locked; workingtree_4,py:commit; decorators.py:write_locked; mutabletree.py:commit; commit.py:commit; workingtree_4.py:update_basis_by_delta; dirstate.py:update_basis_by_delta; dirstate.py: _inv_entry_to_details
la primera pasa por: la segunda pasa por:
test_parents.py:test_utf8_symlink test_parents.py:test_utf_symlink
decorators.py:write_locked mutabletree.py:tree_write_locked
workingtree_4,py:commit workingtree_4.py:set_parent_ids
decorators.py:write_locked mutabletree.py:tree_write_locked
mutabletree.py:commit workingtree_4.py:set_parent_trees
commit.py:commit dirstate.py:set_parent_trees
workingtree_4.py:update_basis_by_delta dirstate.py:_inv_entry_to_details
dirstate.py:update_basis_by_delta  
dirstate.py:_inv_entry_to_details  
1.4.2.5 MALFAR Nº intento, ahora sabiendo por qué falla en Python 2.4
  • CONCLUSIÓN escrita el <16.m02.2009 20:49>
    no sé qué es esto

En repository.py:

elif kind == 'symlink':
    current_link_target = content_summary[3]
    if not store:
        # symlink target is not generic metadata, check if it has
        # changed.
        import pdb; pdb.set_trace()
        if current_link_target != parent_entry.symlink_target:
            store = True
  • current_link_target vale: '9' (bien)
  • parent_entry.symlink_target vale: u'03a9' (¡mal!)
1.4.2.5.1 de dónde viene parent_entry

Pues se lo pasan como parámetro. Esto ya está mal:

(Pdb) p parent_invs[0]['link-id'].symlink_target
u'\u03a9'

1.4.2.5.2 Definición del problema

Para lista.

The problem shows itself at repository.py, line ~400:

elif kind == 'symlink':
    current_link_target = content_summary[3]
    if not store:
        # symlink target is not generic metadata, check if it has
        # changed.
        if current_link_target != parent_entry.symlink_target:
            store = True

At that line, current_link_target is '9' but parent_entry.symlink_target is u'03a9'. My uncertain interpretation is that the second one is wrong because it should have been encoded to utf-8 before being written into the repository. Either both stay in unicode or in utf-8, and I think it must be utf-8 because that's what fingerprints are. My guess is that whoever wrote that u'03a9' to the inventory should have encoded it to utf-8. And that would be workingtree_4.py, around line 1590:

elif kind == 'symlink':
    inv_entry.executable = False
    inv_entry.text_size = None
    inv_entry.symlink_target = utf8_decode(fingerprint)[0]

That could be changed to just „inv_entry.symlink_target = fingerprint“ to always use utf-8. Is that correct? I'd appreciate anyway some pointers to the right direction.

1.4.2.5.2.1 MALFAR esperar respuesta, corregir, …
  • CONCLUSIÓN escrita el <09.m02.2009 01:38>
    mi parche no sirve, está anticuado y más me vale rehacerlo para aprender algo útil

Tengo ya un parche que lo corrige, pero muy feo. En : /w/bzr/fix_bug_272444 ;

1.4.2.6 sacado en claro: decisiones sobre codificaciones. <16.m02.2009 20:59>

Después de leer mucho y recopilar muchos comentarios:

  • al leer un „destino de enlace simbólico“ (ddes) de disco, hay que decodificarlo mediante la cod. del sifi hacia Unicode
  • al crear un ddes en disco, hay que codificarlo desde Unicode hacia la cod. del sifi
  • sin embargo, internamente usamos Unicode y utf-8: Unicode para todos los objetos en memoria, utf-8 para los en disco
  • ŭJAM (John Arbash Meinel, autoridad en esto): el fichero dirstate se ha de grabar en UTF-8
  • ŭJAM el „texto del inventario“ se ha de grabar en utf-8
  • ŭ1 dirstate tiene una parte en disco (fichero) pero luego se pasa a memoria; la parte discada va en utf-8 y la memorizada en Unicode
  • todas las cadenas de dirstate van en utf-8, lo pone en dirstate.py. Dijo JAM en marzo de 2007 que se refactorizó para ganar eficiencia: dirstante procede en utf-8 pero luego lo pasa a las capas superiores en Unicode, que es más cómodo
  • fingerprint, debido a ser de dirstate, también es una cadena utf-8 que contiene el ddes. No es Unicode
  • ŭ1JAM y con mucha convicción inv_entry.symlink_target debería ser Unicode
1.4.2.7 IS nuevo intento usando #319317
  • CONCLUSIÓN escrita el <16.m02.2009 16:01>
    me ayudó a mejorar y a probar otras cosas; sigo probando (ver más abajo)

file:///w/bzr/arra272444_ene09/bzrlib/workingtree.py

cd /n; bzr=/w/bzr/arra272444_ene09/bzr;  rm -rf br1 br2; mkdir br1; cd br1; $bzr init .; touch més; ln -s més prova; $bzr add prova; $bzr commit -m "link to utf-8 file name"; cd ..; $bzr branch br1 br2

1.4.2.7.1 lo que corrigió el 319317 en la revisión 2353 de bzr-svn
=== modified file 'workingtree.py'
--- workingtree.py	2009-01-18 05:25:19 +0000
+++ workingtree.py	2009-01-20 22:28:59 +0000
@@ -304,7 +304,7 @@
             if os.path.islink(self.abspath(relpath)):
                 file = InventoryLink(id, os.path.basename(relpath), parent_id)
                 file.revision = revid
-                file.symlink_target = os.readlink(self.abspath(relpath))
+                file.symlink_target = os.readlink(self.abspath(relpath).encode(osutils._fs_enc))
                 file.text_sha1 = None
                 file.text_size = None
                 file.executable = False
@@ -658,7 +658,7 @@
         elif kind == 'directory':
             return kind, None, None, None
         elif kind == 'symlink':
-            return ('symlink', None, None, os.readlink(abspath))
+            return ('symlink', None, None, os.readlink(abspath.encode(osutils._fs_enc)))
         else:
             return (kind, None, None, None)
1.4.2.7.2 parece que se ha colado algo UTF-8 en el inventario… ¡error mío! Eso no es malo

Creía que „Además es str.; debería ser unicode“, pero no, según JAM: Which means that we probably need to decode the string when we read it from disk, track it in memory as a Unicode string, store it into our inventories as UTF-8, and then encode it when we go to create the symlink.


@@@@@@@@@@142857, invtext:  <type 'str'>
@@@@@ amb contingut:  1dcl441-bugs@yahoo.com-20090121124657-p9tpltb4b4apbl1y
0
TREE_ROOTd0nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxd0ndcl441-bugs@yahoo.com-20090121124657-p9tpltb4b4apbl1y
provaprova-20090121124656-2kluxcf86nk8s591-1l0nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxlmés0ndcl441-bugs@yahoo.com-20090121124657-p9tpltb4b4apbl1y

bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 267: ordinal not in range(128)

Traceback (most recent call last):
1.4.2.7.2.1 entonces el error es querer meter Unicode dentro del inventario

Le quito los encode

1.4.2.8 IS leer y aplicar esta información
1.4.2.9 IS seguir buscando los errores y adaptando a mano
cd /n; bzr=/w/bzr/arra272444_feb09/bzr;  rm -rf br1 br2; mkdir br1; cd br1; $bzr init .; touch més; ln -s més prova; $bzr add prova; $bzr commit -m "link to utf-8 file name"; cd ..; $bzr branch br1 br2

1.4.2.9.1 IS buscar quién pone inv_entry.symlink_target a str; ha de ser Unicode

dirstate.py Buscar esto:

print "[44444  142857, inv_entry.symlink_target (-u Unicode, JAM): ", type(inv_entry.symlink_target)
# 16.2.2009: seguir buscando el origen; alguien lo mete como str y eso es malo

1.4.2.9.1.1 encontrado y por primera vez arranca y bifurca sin errores

====22  142857, inv_entry.symlink_target (-u Unicode, JAM):  <type 'NoneType'>
====22b  142857, inv_entry.symlink_target (-u Unicode, JAM):  <type 'NoneType'>
ddddddd2: acabo de poner ie.symlink_target= més  de tipo  <type 'str'>
added prova
[55555  142857, inv_entry.symlink_target (-u Unicode, JAM):  <type 'NoneType'>

En repository.py

ie.symlink_target = current_link_target
print "ddddddd2: acabo de poner ie.symlink_target=", ie.symlink_target, " de tipo ", type(ie.symlink_target)

El truco:

=== modified file 'bzrlib/repository.py'
--- bzrlib/repository.py	2009-01-27 07:48:55 +0000
+++ bzrlib/repository.py	2009-02-16 19:43:04 +0000
@@ -469,6 +469,9 @@
             self._add_text_to_weave(ie.file_id, lines, heads, None)
         elif kind == 'symlink':
             current_link_target = content_summary[3]
+            # puede que me toque pasarlo a Unicode
+            current_link_target = content_summary[3].decode("utf-8")
+            
             if not store:

El truco está apuntado en sacado en claro: decisiones sobre codificaciones. <2009-02-16 dl 20:59>

1.4.2.10 IS que pase los juegos de pruebas
1.4.2.10.1 los de test_unicode_symlink

No me lo puedo creer


----------------------------------------------------------------------
Ran 15 tests in 7.951s

OK
tests passed                                                                                                
1.4.2.10.2 IS el resto
  • CONCLUSIÓN escrita el <16.m02.2009 22:00>
    ¡los pasa! increíble
time ./bzr selftest --no-plugins

1.4.2.11 IS limpiar código, quitar basura
1.4.2.11.1 versión limpia contra bzr.dev, pasa los tests

: /w/bzr ; bzr.dev diff --old oficial --new arra272444_feb09_limpio/ 
=== modified file 'bzrlib/dirstate.py'
--- bzrlib/dirstate.py	2009-01-28 10:38:03 +0000
+++ bzrlib/dirstate.py	2009-02-16 20:32:15 +0000
@@ -1866,8 +1866,8 @@
             size = 0
             executable = False
         elif kind == 'symlink':
-            # We don't support non-ascii targets for symlinks yet.
-            fingerprint = str(inv_entry.symlink_target or '')
+            # fingerprint is always a utf-8 string (not unicode)
+            fingerprint = inv_entry.symlink_target.encode("utf-8") or ''
             size = 0
             executable = False
         elif kind == 'file':
@@ -1952,6 +1952,8 @@
         output_lines = [DirState.HEADER_FORMAT_3]
         lines.append('') # a final newline
         inventory_text = '\0\n\0'.join(lines)
+
+        # all the inventory text is in utf-8 and therefore zlib.crc32 is valid
         output_lines.append('crc32: %s\n' % (zlib.crc32(inventory_text),))
         # -3, 1 for num parents, 1 for ghosts, 1 for final newline
         num_entries = len(lines)-3

=== modified file 'bzrlib/inventory.py'
--- bzrlib/inventory.py	2008-12-11 20:59:28 +0000
+++ bzrlib/inventory.py	2009-02-16 20:36:36 +0000
@@ -662,7 +662,10 @@
     def _put_on_disk(self, fullpath, tree):
         """See InventoryEntry._put_on_disk."""
         try:
-            os.symlink(self.symlink_target, fullpath)
+            # the link target (now in unicode) must be created in disk using the
+            # file system encoding, so that it still works across systems with
+            # differents encodings
+            os.symlink(self.symlink_target.encode(osutils._fs_enc), fullpath)
         except OSError,e:
             raise BzrError("Failed to create symlink %r -> %r, error: %s" % (fullpath, self.symlink_target, e))
 

=== modified file 'bzrlib/repository.py'
--- bzrlib/repository.py	2009-01-27 07:48:55 +0000
+++ bzrlib/repository.py	2009-02-16 20:38:21 +0000
@@ -469,6 +469,10 @@
             self._add_text_to_weave(ie.file_id, lines, heads, None)
         elif kind == 'symlink':
             current_link_target = content_summary[3]
+            # The symlink_target in an inventory entry should always be Unicode.
+            # Currently we have it stored in disk in utf-8, so we must decode.
+            current_link_target = content_summary[3].decode("utf-8")
+            
             if not store:
                 # symlink target is not generic metadata, check if it has
                 # changed.

=== modified file 'bzrlib/workingtree_4.py'
--- bzrlib/workingtree_4.py	2008-12-22 08:44:20 +0000
+++ bzrlib/workingtree_4.py	2009-02-16 20:40:13 +0000
@@ -1697,9 +1697,8 @@
         if entry[1][parent_index][0] != 'l':
             return None
         else:
-            # At present, none of the tree implementations supports non-ascii
-            # symlink targets. So we will just assume that the dirstate path is
-            # correct.
+            # Support for non-ascii symlink targets is being worked on (bug #272444).
+            # We will just assume now that the dirstate path is correct.
             return entry[1][parent_index][1]
 
     def get_revision_id(self):

: /w/bzr ; 

1.4.2.12 IS enviar a bzr

La versión ésta: versión limpia contra bzr.dev, pasa los tests

: /w/bzr/arre_272444 ; bzr.dev send lp:bzr -o ../fix_272444_v1.patch

1.4.2.12.1 digo entre otras cosas

suppositions:

  • when you read a symlink target from disk, you must decode it to Unicode via the file system encoding
  • when you write a symlink to disk, you must encode it from Unicode to the file system encoding
  • internally, Bazaar will use Unicode objects in memory and UTF-8 strings in files
  • dirstate, according to its documentation, stores/handles everything in UTF-8. I think this is for performance
  • somethink called „inventory text“ which I don't understand much must be stored in UTF-8
  • I think that dirstate has a part in disk and other in memory; the disk one is in UTF-8 and the memory one in Unicode
  • the fingerprint (which for symlinks is equal to the symlink target) is UTF-8 because it is part of dirstate
  • inv_entry.symlink_target should be Unicode

I hope you can correct or improve my patch, specially:

  • test in other systems (other platforms, other Python versions, other encodings)
  • check that it is complete (for instance, when reading from disk we should probably decode the link target to Unicode – I don't know if the patch does this)
  • remove outdated and incorrect comments
  • correct misunderstandings about encodings… and maybe write more explanations about this in the code or in the wiki
1.4.2.12.3 MALFAR ver si responden
  • CONCLUSIÓN escrita el <23.m03.2009 11:17>
    acabó hace tiempo bien
1.4.2.13 vila hizo otro parche

y funciona bien

1.4.2.13.1 IS ver si incluyen el suyo… en vez del mío :-(
  • CONCLUSIÓN escrita el <12.m03.2009 09:57>
    incluyeron el suyo; mejor

Al menos me dijo:

And thanks for your earlier work on the subject, it helps me a lot. Vincent

1.4.2.14 prueba final tras corregir el fallo
cd ; git fast-export -M -C --all | (cd ~/n; rm -rf cacba3; mkdir cacba3; cd cacba3; bzr.dev init; time bzr.dev fast-import -)

1.4.3 BONUS otros fallos de Unicode pero ahora en fast-import

Probar:

(cd ~ ; git fast-export -M -C --all ; cd -)  | time /w/bzr/arra272444_feb09_limpio/bzr fast-import -

1.4.3.1 IS falla con mi versión de bzr parcheado
  • CONCLUSIÓN escrita el <15.m03.2009 16:46>
    a mí me va, falta integrarlo

El <04.m03.2009 15:25>:


  File "/home/dc/.bazaar/plugins/fastimport/processors/generic_processor.py", line 404, in commit_handler
    handler.process()
  File "/home/dc/.bazaar/plugins/fastimport/processor.py", line 200, in process
    handler(self, fc)
  File "/home/dc/.bazaar/plugins/fastimport/bzr_commit_handler.py", line 391, in modify_handler
    filecmd.is_executable, data, self.inventory)
  File "/home/dc/.bazaar/plugins/fastimport/bzr_commit_handler.py", line 183, in _modify_item
    ie.symlink_target = data.encode('utf8')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)

Tocar: file:///home/dc/.bazaar/plugins/fastimport/bzr_commit_handler.py

Pruebo:

#ie.symlink_target = data.encode('utf8')
# 142857
ie.symlink_target = data
1.4.3.1.1 segundo error tras esta corrección

: ~/n/cacba ; (cd ~ ; git fast-export -M -C --all ; cd -)  | time /w/bzr/arra272444_feb09_limpio/bzr fast-import -
15:36:12 1000 commits processed (:9259)
fatal: Could not read blob b2117bd27d42c6660240a464859b92cd0b5ee454
bzr: ERROR: line 8248944: Invalid command '/home/dc/n/cacba'
Command exited with non-zero status 3
888.76user 27.58system 15:45.38elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
96inputs+134360outputs (0major+5755752minor)pagefaults 0swaps

Solución intentada:

cd ; git fast-export -M --all | (cd /n; rm -rf cacba; mkdir cacba; cd cacba; bzr.dev init; time /w/bzr/arra272444_feb09_limpio/bzr fast-import -)

Falta -C

1.4.3.1.2 tercer error con stash

fatal: Could not read blob b2117bd27d42c6660240a464859b92cd0b5ee454
16:10:15 Updating branch information ...
las partes  []  category:  stash  ref_name:  refs/stash  y  ['refs/stash']
bzr: ERROR: exceptions.IndexError: list index out of range

Traceback (most recent call last):
…
  File "/home/dc/.bazaar/plugins/fastimport/branch_updater.py", line 58, in update
    branch_tips, lost_heads = self._get_matching_branches()
  File "/home/dc/.bazaar/plugins/fastimport/branch_updater.py", line 84, in _get_matching_branches
    git_to_bzr_map = self.name_mapper.git_to_bzr(ref_names)
  File "/home/dc/.bazaar/plugins/fastimport/branch_mapper.py", line 40, in git_to_bzr
    name_no_ext = self._git_to_bzr_name(parts[-1])
IndexError: list index out of range

Sol: borro stash

1.4.3.1.3 por fin parece funcionar
: ~ ; cd ; git fast-export -M -C --all | (cd /n; rm -rf cacba; mkdir cacba; cd cacba; bzr.dev init; time /w/bzr/arra272444_feb09_limpio/bzr fast-import -)
Created a standalone tree (format: pack-0.92)
16:29:03 1000 commits processed (:9259)
fatal: Could not read blob b2117bd27d42c6660240a464859b92cd0b5ee454
16:36:36 Updating branch information ...
	 branch cacba now has 1221 revisions and 0 tags
16:36:36 Imported 1790 revisions, updating 1 branch and 0 trees in 0:14:55
To refresh the working tree for a branch, use 'bzr update'.

real	14m55.195s
user	14m0.977s
sys	0m26.346s
: ~ ; 
1.4.3.1.4 IS corregir fallo oficial de fast-import sobre enlaces a utf-8
  • CONCLUSIÓN escrita el <20.m12.2010 01:33>
    ya en oficial. No lo he probado (pues hay otros problemas de bzr que me lo impiden) pero confío en que funcionará bien

https://bugs.launchpad.net/bzr-fastimport/+bug/238365

No pasa nada. ¿Debería pedir una mezcla de ramas? <05.m01.2010>: pido mezcla de ramas

Tras 9 meses, la propuesta aún dice: „Status: Pending“ El <11.m12.2010> se mezcla y ya está en oficial.

1.4.3.1.4.1 identificación y primeras ideas

¿Otro? error de ¬UTF-8 debido a nombres de enlaces simbólicos

(Es de lo que se queja realmente fastimport).

 File "/home/dc/.bazaar/plugins/fastimport/processors/generic_processor.py", line 807, in _modify_inventory
   ie.symlink_target = data.encode('utf8')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)

Posible problema: git-fast-export graba un enblance („enlace blando“) como un blob. Y hemos quedado en que git-fast-export vuelca los blobs en crudo. Por tanto, si un nombre estaba en iso-8859-1, no lo va a adaptar a utf-8.

Para probar, buscar „org-export-latex.el“ pues apuntó a „mía.el“ Es precisamente ése el que está falligando.

  • Estoy en el punto peligroso; con file_id: emacs.dorgexportlate-20080608104515-02pf1ss16l7lyvpx-724
  • La ruta es .emacs.d/org-export-latex/org-export-latex.el
  • Y los datos mía.el
bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)

  • los nombres en utf-8 sí que van bien

Quizás:

  • git-fast-export debería traducir los enlaces simbólicos a utf-8. Malo <= se pierde información
  • bzr fast-import debería permitir nombres de ficheros en diversas codificaciones.
1.4.3.1.4.2 IS primeros parches

Mandé parche.

Enviado recordatorio a lista el <25.m08.2009 11:10>.

Enviado segundo parche el <22.m10.2009>. Le he añadido el decode("utf8"). Mandé hasta la v5, con la que ya casi funcionó todo… hasta que encontré un error con nombres con barra invertida (\).

1.4.3.1.4.3 IS creo rama con correcciones

Ian me pide:

  • [X] crear rama
  • [X] fast-import ha de ir
  • [X] fast-export ha de ir
  • [X] fast-import-filter ha de ser neutro en cuanto a codificación
    • pero ver abajo y contar a Ian lo del 644

Creo rama (web de la rama):

bzr push lp:~n142857/bzr-fastimport/unicode-symlinks -v

1.4.3.1.4.3.1 para probar
cd /n; rm -rf tres enbzr; mkdir tres; cd tres; git init; touch més; ln -s més prova; git add més prova; git commit -a -m "link to a file with a name in utf-8"; git fast-export --all >expo; mkdir enbzr; cd enbzr; bzr init; bzr fast-import ../expo

Más complicado, le mete mano de casi todas formas posibles:

cd /n; rm -rf quatre enbzr; mkdir quatre; cd quatre; git init; touch més; ln -s més prova; git add més prova; git commit -a -m "link to a file with a name in utf-8"; cp -l prova prova2; git add prova2; git commit -a -m "copied symlink"; git mv prova provab; git commit -a -m "moved symlink"; rm provab; touch més2; ln -s més2 provab; git commit -a -m "modified symlink destination"; git rm provab; git commit -a -m "deleted symlink"; git fast-export --all >expo; mkdir enbzr; cd enbzr; bzr init; bzr fast-import ../expo

1.4.3.1.4.3.2 creo que cuando dice „data XX“, ese XX se refiere al número de caracteres, no de bytes, y yo estoy dando el de bytes, por eso está mal

Pero parece que no da problemas… Tendría que revisarlo o pasarlo por juegos de prueba

1.4.3.1.4.3.3 tras filtrar voy a ignorar estas diferencias porque creo que no son relevantes
-M 100644 :1 més
-M 120000 :2 prova
 
+M 644 :1 més
+M 120000 :2 prova
+
 from :3
 M 120000 :2 prova2
-
+blob
+mark :2
+data 4
+més
 commit refs/heads/master
 mark :5
 author Daniel Clemente Laboreo <dc@ali.(none)> 1256944975 +0100
 committer Daniel Clemente Laboreo <dc@ali.(none)> 1256944975 +0100
 data 14
 moved symlink
+
1.4.3.2 MALFAR otro fallo de Unicode con el que me encontraré más adelante
  • CONCLUSIÓN escrita el <22.m10.2009 17:41>
    ya no falla o lo he evitado de alguna otra forma
1.4.3.2.1 excepción tras 33 minutos

: ~ ; cd ; git fast-export -M -C --all > ~/n/mirepogit && (echo fin de git ; cd ~/n; rm -rf repoCasaBzr; mkdir repoCasaBzr; cd repoCasaBzr; bzr.dev init; time bzr.dev fast-import ~/n/mirepogit)
…
/Werkstatt/bzr/oficial/bzrlib/inventory.py:850: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  delta if np is not None):
bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 15: ordinal not in range(128)

Traceback (most recent call last):
  File "/Werkstatt/bzr/oficial/bzrlib/commands.py", line 727, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/Werkstatt/bzr/oficial/bzrlib/commands.py", line 922, in run_bzr
    ret = run(*run_argv)
  File "/Werkstatt/bzr/oficial/bzrlib/commands.py", line 559, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/dc/.bazaar/plugins/fastimport/__init__.py", line 221, in run
    params, verbose)
  File "/home/dc/.bazaar/plugins/fastimport/__init__.py", line 75, in _run
    return proc.process(p.iter_commands)
  File "/home/dc/.bazaar/plugins/fastimport/processor.py", line 92, in process
    self._process(command_iter)
  File "/home/dc/.bazaar/plugins/fastimport/processors/generic_processor.py", line 269, in _process
    processor.ImportProcessor._process(self, command_iter)
  File "/home/dc/.bazaar/plugins/fastimport/processor.py", line 114, in _process
    handler(self, cmd)
  File "/home/dc/.bazaar/plugins/fastimport/processors/generic_processor.py", line 458, in commit_handler
    handler.process()
  File "/home/dc/.bazaar/plugins/fastimport/processor.py", line 201, in process
    self.post_process_files()
  File "/home/dc/.bazaar/plugins/fastimport/bzr_commit_handler.py", line 534, in post_process_files
    lambda revision_ids: self._get_inventories(revision_ids))
  File "/home/dc/.bazaar/plugins/fastimport/revision_store.py", line 236, in load_using_delta
    rev_id, basis_inv, inv_delta, present_parents, parent_invs)
  File "/home/dc/.bazaar/plugins/fastimport/revision_store.py", line 313, in _add_inventory_by_delta
    inv_delta, revision_id, parents)
  File "/Werkstatt/bzr/oficial/bzrlib/repository.py", line 1032, in add_inventory_by_delta
    basis_inv.apply_delta(delta)
  File "/Werkstatt/bzr/oficial/bzrlib/inventory.py", line 850, in apply_delta
    delta if np is not None):
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 15: ordinal not in range(128)

bzr 1.14dev on python 2.5.4 (linux2)
arguments: ['/usr/local/bin/bzr.dev', 'fast-import', '/home/dc/n/mirepogit']
encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'es_ES.UTF-8'
plugins:
  bzrtools             /home/dc/.bazaar/plugins/bzrtools [1.13]
  fastimport           /home/dc/.bazaar/plugins/fastimport [0.8dev]
  gtk                  /home/dc/.bazaar/plugins/gtk [0.96.0.dev.1]
  launchpad            /Werkstatt/bzr/oficial/bzrlib/plugins/launchpad [unknown]
  netrc_credential_store /Werkstatt/bzr/oficial/bzrlib/plugins/netrc_credential_store [unknown]
  qbzr                 /home/dc/.bazaar/plugins/qbzr [0.9.9dev]
…

real	33m9.397s
user	25m36.172s
sys	0m47.507s

1.4.4 IS mensaje de error de git fast-export cuando yo pasaba de git a bzr probando

  • CONCLUSIÓN escrita el <24.m03.2009 16:54>
    se solucionó con 1.6
Could not read blob b2117bd27d42c6660240a464859b92cd0b5ee454

¡Es del fast-export!

El fichero tiene 8245837 líneas

1.4.4.1 completo contexto
: ~ ; time git fast-export -M -C --all >n/todomigit
fatal: Could not read blob b2117bd27d42c6660240a464859b92cd0b5ee454

real	0m24.628s
user	0m21.269s
sys	0m2.212s
: ~ ; 
1.4.4.2 IS mmm… por eso, está acabando donde no toca. En 1221
  • CONCLUSIÓN escrita el <18.m05.2009 19:59>
    Creo que esto se solucionó, era porque muse era un subproyecto con su propio .git. La nueva versión de git lo trataba bien

1221 Daniel Clemente   2009-01-20
     más

1220 Daniel Clemente   2009-01-20
     ignoradas más cosas

1219 Daniel Clemente   2009-01-20
     preta per veure canvis a repositori git i després portar-los

La siguiente revisión que tocaba era:

traigo muse de CVS; actualización importante pues tenía 3.11, muy antiguo

Nada especial, creo.

Es por el error de b2117. Es justo donde acaba el fast-export :-(

1.4.4.3 IS depurar git
  • CONCLUSIÓN escrita el <24.m03.2009 16:54>
    se solucionó con git 1.6

Esto ya lo reproduce:

git fast-export 933292c8f537d932c0401829ab64834d7bf6f7e0..f9b4a22460d304cb11a892e9c7e1ceb4f804b913

Pues b2117bd27d42c6660240a464859b92cd0b5ee454 está en medio.

1.4.4.3.1 IS probar en CPU107 pues en ali con git 1.6.1.3 no falla
  • CONCLUSIÓN escrita el <09.m03.2009 10:37>
    He de usar git 1.6

Sino que le añadieron el M 160000


commit (null)
mark :1
author Daniel Clemente <dc@CPU107.(none)> 1232480834 +0100
committer Daniel Clemente <dc@CPU107.(none)> 1232480834 +0100
data 76
traigo muse de CVS; actualización importante pues tenía 3.11, muy antiguo
M 160000 b2117bd27d42c6660240a464859b92cd0b5ee454 .emacs.d/muse
D .emacs.d/muse/.gitignore
D .emacs.d/muse/Makefile
D .emacs.d/muse/muse-autoloads.el

En CPU107, en cambio, tengo git 1.5.6.3. Por eso falla

1.4.4.3.2 ¿qué es esto de Subproject?

commit f9b4a22460d304cb11a892e9c7e1ceb4f804b913
Author: Daniel Clemente <dc@CPU107.(none)>
Date:   Tue Jan 20 20:47:14 2009 +0100

    traigo muse de CVS; actualización importante pues tenía 3.11, muy antiguo

diff --git a/.emacs.d/muse b/.emacs.d/muse
new file mode 160000
index 0000000..b2117bd
--- /dev/null
+++ b/.emacs.d/muse
@@ -0,0 +1 @@
+Subproject commit b2117bd27d42c6660240a464859b92cd0b5ee454
diff --git a/.emacs.d/muse/.gitignore b/.emacs.d/muse/.gitignore
deleted file mode 100644
index b70794e..0000000
--- a/.emacs.d/muse/.gitignore
+++ /dev/null
@@ -1,9 +0,0 @@
-# Files that we ignore when using git.
-
-*~
-/++xgit-log-edit
-*.elc
-/Makefile.defs
-/lisp/muse-autoloads.el
-/texi/muse.info
-/texi/muse.html
…
1.4.4.3.3 vale, ya sé por qué es

Es por lo de meter un .git (dentro de muse) dentro de mi .git (de ~). Algo se ha liado…

1.4.4.3.4 IS probar otra vez con git 1.6
  • CONCLUSIÓN escrita el <16.m03.2009 02:24>
    va mejor
1.4.4.4 IS corregir mi repositorio (git-fsck …)
  • CONCLUSIÓN escrita el <18.m05.2009 19:53>
    No encontró nada en CPU107 un –strict –full

dangling blob 655465f104bfb6e58388e3882b3f002e432c804f
dangling blob a194dfd2051e862a82d32ef7220f9088927b5d58
dangling blob b0d44ecf904cdd0585076d8d2ac7873da432c90d
dangling blob ba14588a97ce04739dde313311724dbb2a42aa22
dangling commit f2143bfad53fd1d5aeb16d08150b02e9264fb931
dangling blob 1d558b18a7cf7e5f0f64987f29f65533947cf87f
dangling blob 21159922dd9767f36ad5f55f1d74b017e1cdc758
dangling blob 3015cf7ecd95bb2de0adcb029f5d50c21ea96580

: git-fsck --strict --full:

real	0m34.204s
user	0m31.550s
sys	0m1.236s

: ~ ;  git-fsck --strict --full |wc
    380    1140   20912

1.4.5 IS otro error que sale en „log“ quizás por contenido en ¬UTF-8

  • CONCLUSIÓN escrita el <12.m03.2009 15:50>
    lo han corregido en bzr.dev
1.4.5.1 mensaje de log
: ~/n/cacba2 ; time /w/bzr/arra272444_feb09_limpio/bzr  log -p -r 1220
------------------------------------------------------------
revno: 1220
committer: Daniel Clemente <dc@CPU107.(none)>
timestamp: Tue 2009-01-20 18:29:53 +0100
message:
  ignoradas más cosas
diff:
=== modified file '.gitignore'
--- .gitignore	2009-01-20 10:40:11 +0000
+++ .gitignore	2009-01-20 17:29:53 +0000
@@ -202,6 +202,7 @@
 /.cvsps
 /.arch-params
 /.bzr.log
+/.bzr.log.old
 /.bazaar/gannotate.conf
 /.bazaar/qbzr.conf
 /.bazaar/locations.conf
@@ -264,6 +265,7 @@
bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4: ordinal not in range(128)

Traceback (most recent call last):
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/commands.py", line 921, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/commands.py", line 866, in run_bzr
    ret = run(*run_argv)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/commands.py", line 547, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/commands.py", line 881, in ignore_pipe
    result = func(*args, **kwargs)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/builtins.py", line 2095, in run
    show_diff=show_diff)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/log.py", line 182, in show_log
    start_revision, end_revision, search, limit, show_diff)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/log.py", line 239, in _show_log
    lf.log_revision(lr)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/log.py", line 1248, in log_revision
    self.show_diff(to_file, revision.diff, indent)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/log.py", line 1193, in show_diff
    to_file.write(indent + '%s\n' % (l,))
  File "/usr/lib/python2.5/codecs.py", line 303, in write
    data, consumed = self.encode(object, self.errors)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4: ordinal not in range(128)

1.4.5.2 mensaje según diff

: ~/n/cacba2 ; time /w/bzr/arra272444_feb09_limpio/bzr  diff -c 1220
=== modified file '.gitignore'
--- .gitignore	2009-01-20 10:40:11 +0000
+++ .gitignore	2009-01-20 17:29:53 +0000
@@ -202,6 +202,7 @@
 /.cvsps
 /.arch-params
 /.bzr.log
+/.bzr.log.old
 /.bazaar/gannotate.conf
 /.bazaar/qbzr.conf
 /.bazaar/locations.conf
@@ -264,6 +265,7 @@
 # más de emacs
 /.org-timestamps
 /.org-id-locations
+/.emacs.d/.org-id-locations
 /.projects.ede
 /.ecb-tip-of-day.el
 /.abbrev_defs
@@ -321,6 +323,8 @@
1.4.5.3 es un fallo conocido

1.4.6 MALFAR error de Unicode al hacer fast-export

: ~/n/cacba2 ; time /w/bzr/arra272444_feb09_limpio/bzr fast-export .
commit refs/heads/master
mark :1
committer clemente <clemente@70fd8048-8397-4fc7-9837-f1471fe56640> 1192718941 +0000
data 93
Primera prueba


git-svn-id: file:///tmp/.rehejmalŝl@1 70fd8048-8397-4fc7-9837-f1471fe56640

M 644 inline prueba.txt
data 33
Fichero dentro de mi repositorio

commit refs/heads/master
mark :2
committer clemente <clemente@70fd8048-8397-4fc7-9837-f1471fe56640> 1192721187 +0000
data 105
Ignorados algunos ficheros


git-svn-id: file:///tmp/.rehejmalŝl@2 70fd8048-8397-4fc7-9837-f1471fe56640

from :1
bzr: ERROR: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\xed' in position 70: ordinal not in range(128)

Traceback (most recent call last):
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/commands.py", line 921, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/commands.py", line 866, in run_bzr
    ret = run(*run_argv)
  File "/home/w/bzr/arra272444_feb09_limpio/bzrlib/commands.py", line 547, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/dc/.bazaar/plugins/fastimport/__init__.py", line 418, in run
    return exporter.run()
  File "/home/dc/.bazaar/plugins/fastimport/bzr_exporter.py", line 69, in run
    self.emit_commit(revid, self.git_branch)
  File "/home/dc/.bazaar/plugins/fastimport/bzr_exporter.py", line 154, in emit_commit
    file_cmds))
  File "/home/dc/.bazaar/plugins/fastimport/bzr_exporter.py", line 85, in print_cmd
    self.outf.write("%r\n" % cmd)
  File "/home/dc/.bazaar/plugins/fastimport/commands.py", line 155, in __repr__
    for c in iter(self.file_iter)])
UnicodeEncodeError: 'ascii' codec can't encode character u'\xed' in position 70: ordinal not in range(128)

bzr 1.13dev on python 2.5.2 (linux2)
arguments: ['/w/bzr/arra272444_feb09_limpio/bzr', 'fast-export', '.']
encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'ca_ES.UTF-8'
plugins:

1.4.7 informaciones sueltas (de wiki) sobre estos fallos

1.4.7.1 solución de muchos fallos de Unicode con bzr

bzr 1.6b2, del 10 de junio de 2008, incluye entre otras cosas:

  • Squash ``inv_entry.symlink_target`` to a plain string when generating DirState details. This prevents from getting a ``UnicodeError`` when you have symlinks and non-ascii filenames. (John Arbash Meinel, #135320)

https://bugs.launchpad.net/bzr/+bug/135320

Aunque dicen que aún falla.

Lo he probado un poco y veo que no se me arregla porque quien falla es fast-import. He escrito en #135320 una referencia al mío, 238365

1.5 ATENDAS ni fast-import ni Bazaar permiten los nombres de fichero que contienen \ (barra invertida)

Encontrado mientras exportaba mi casa de git a bzr: https://bugs.launchpad.net/bzr-fastimport/+bug/458260

Pero el fallo es de Bazaar (el segundo más informado según aparece en los listados): https://bugs.launchpad.net/bzr/+bug/81844

Lo necesito corregido para poder exportar esa rama.

Aparentemente dos pasos (confirmado con Jelmer por IRC). Anotado en informe:

A solution, as suggested in comment 6, consists in two steps:
- bzr has to allow \ in names: see bug 163858 for that
- the importer should convert \ in file ids (is there a bug for this?)

Ver por tanto: https://bugs.launchpad.net/bzr/+bug/163858

No tienen mucho interés en corregirlo. En cambio, a mí me impide usar Bazaar.

1.6 BONUS ¿los ficheros no se están ignorando bien?

<21.m11.2008>, me pasa esto:

: /n/bzr01 ; cd /n; rm -rf bzr01; mkdir bzr01; cd bzr01; bzr init; echo test >one; bzr add one; bzr commit -m "commited one"; bzr ignore one; echo "changed" >one; echo STATUS:; bzr status;
Standalone tree (format: pack-0.92)
Location:
  branch root: .
added one
Committing to: /home/n/bzr01/
added one
Committed revision 1.
Warning: the following files are version controlled and match your ignore pattern:
one
STATUS:
added:
  .bzrignore
modified:
  one

¡Yo esperaba que „one“ no saliere!

1.6.1 descripción del problema

Para IRC:

In a project I have some files which need to be there after a checkout, so I added them to my branch. But they change too much and I'd like to ignore them. How can I ignore a file's modifications without having to remove the file from the index?

I have an important file in my branch, but now it's changing too frequently and I would like to ignore it. Bazaar won't ignore it because it is versioned, and I can't remove it because most of its content is important. What can I do? As an example, take my bazaar.conf: most settings are meaningful and I want them tracked, but there are also lines like „viz-window-size = 1022x734“ whose changes I don't want to track.

Lo que quiero: Ignore versioned files. No es esto: Version ignored files.

Ejemplos:

  • Un fichero de contador: /count, que ha de existir y contener un número, y que con cada ejecución de mi programa se incrementa.
  • Un „Makefile“ que cambia al hacer el „./configure“, pero que ha de estar en el repo pues es parte del proyecto.

En documentación encontré: It is OK to have either an ignore pattern match a versioned file, or to add an ignored file. Ignore patterns have no effect on versioned files; they only determine whether unversioned files are reported as unknown or ignored.

Y más: John A Meinel said on 2008-04-03: … * just ignores everything in that directory. Also, if things are versioned they will continue to be versioned (so you may need to do 'bzr rm –keep' cache/* to unversion them).

Mis soluciones:

  • Si algo tiene que formar parte del proyecto, pues me va a tocar entrarlo en la rama tras cada cambio.
  • Puedo dar un prita 'post-checkout' que 1.) ignore algunos ficheros que se bajaron junto con el 'checkout' y que 2.) los borre del índice

1.6.2 curioso, git hace lo mismo

cd /n; rm -rf git01; mkdir git01; cd git01; git init ; echo test>one; git add one; git commit -m "commited one"; echo "/one" >.gitignore; git add .gitignore; git commit -m "ignored"; echo "changed">one; echo STATUS:; git status

1.6.3 y lo que recomienda Svn es chapucero

1.7 BONUS "bzr missing" repetitivo es muy lento

1.7.1 Fallo mandado el <04.m02.2009 13:54> y mensaje a lista

> > Any idea what this could be? It would seem that this is an obvious place > for future optimisation.

It is like when you do "bzr missing" again and again: it keeps downloading everything in each run (instead of storing the revisions in the local branch). I filed a new bug for that: https://bugs.launchpad.net/bzr/+bug/325278

1.7.1.1 IS ver respuesta en lista de Bazaar
  • CONCLUSIÓN escrita el <09.m02.2009 01:35>
    sigue el informerro; en la lista se habló poco

1.8 IS tests (selftest) en paralelo

  • CONCLUSIÓN escrita el <19.m06.2009 09:00>
    ya tenemos –selftest, que va bien (aunque es mejorable)

https://bugs.launchpad.net/bzr/+bug/330269

1.8.1 BONUS documentar selftest –parallel

Pues no quedan claros los valores posibles

1.8.2 BONUS que sea siempre –parallel

Difícil pues requiere subunit etc.

1.9 se queja de pyqt4 si lo uso dentro de virtualenv

(ent): dc; ~/.nyiw/servrwrtr ; bzr help commands bzr: ERROR: No module named PyQt4 You may need to install this Python library separately.

2 extensiones de Bazaar

2.1 mejoras al sistema de repositorios (colecciones de ramas)

2.1.1 BONUS aprender scm-proj pues lo necesito para mis proyectos

scmproj es la versión previa y pobre de „nested trees“; me lo dijeron al preguntar en lista.

http://linux.softpedia.com/get/Programming/Version-Control/ScmProj-45189.shtml

Es lo que me hacía falta; a ver si es fácil…

# ~ ; cd .bazaar/plugins/ # ~/.bazaar/plugins ; bzr branch lp:bzr-scmproj scmproj

De momento no me atrevo a aprenderlo porque me daría otra forma más de trabajo, con nuevos comandos, conceptos, etc. Preferiría una integración mayor con Bazaar para poder aprovechar los conocimientos que ya aprendí sobre.

2.1.1.1 BONUS más o menos aporta:
  • project-command Run some command(s) for project components. [scmproj]
  • project-commit Commit changes in components working copies. [scmproj]
  • project-get Get a copy of an existing project on your local disk. [scmproj]
  • project-info Show info summary for project. [scmproj]
  • project-init Initialize new top-level branch for the project. [scmproj]
  • project-publish Publish (push back) changes from components branches and control branch. [scmproj]
  • project-update Update components of the project from their origins. [scmproj]
2.1.1.2 infos

I have a project that I would like to break up into several independently developed subprojects. Each is useful on its own and I would like to make them available independently. I think that part is not difficult. Then I'd like to configure a master bzr branch that pulls in a branch from each of the subprojects, and tracks changes in each of the subproject branches. Is this possible with bzr?

This is more or less what https://launchpad.net/bzr-scmproj does for you. It is still quite new/alpha. But I already find it extremely useful for this sort of use case.

2.1.2 Conseguir alguna forma de hacer „push“ de un repositorio

2.1.2.1 La combinación repo-push y multi-pull es muy cutre

Quizás me estoy dejando algo, pero…

  • no está integrada (interfaz distinta para cada herramienta)
  • da errores raros incomprensibles (Not a branch: /home/dc/desaweb/oficial)
  • no se entiende qué está haciendo (o si hace algo); siempre dice Pulling
  • no da información sobre qué revisiones ha traído
  • no es oficial
2.1.2.2 IS bzr branch lp:bzr-repo-push

Instaŀlat

Va molt bé. Però i el pull?

2.1.2.3 IS preguntar quina és la manera bona de fer push/pull/¿branch? de repositori
  • CONCLUSIÓN escrita el <18.m05.2009 19:44>
    escrito a lista ahora mismo

Por curiosidad pues ya me irá bien una por una manualmente.

2.1.2.3.1 IS ver si responden de bzr sobre push/pull de repo
  • CONCLUSIÓN escrita el <09.m06.2009 20:26>
    pues ya lo hicieron: „nested branches“ es la solución

    ,-—

    in the long run you need nested trees.
    Right now you can use scmproj as [poor] emulation of nested trees.

    `-—

2.1.2.4 MALFAR quiàs de hace con las „colocated branches“, de las que hablan sobre el <10.m02.2009>
  • CONCLUSIÓN escrita el <09.m06.2009 20:27>
    No, ver abajo.

Es justo lo que quiero.

+Brad has a single project with a lot of related branches. He works on +them and occasionally pushes all of those branches to a remote host +using a single push command.

2.1.2.5 MALFAR quizás es con „loom“
  • CONCLUSIÓN escrita el <09.m06.2009 20:27>
    Me dijeron sobre mi comentario: ,-—

    Subtract loom and colocated branches, which are
    for switching among closely related branches of the same basic
    content,

    `-—

2.1.3 BONUS impulsar lo de ramas colocadas (corramas): viven todas en el mismo sitio

Por ahora (<30.m09.2009>) aún no está, y lo necesito.

Me molesta mucho el siguiente escenario: quiero tener 4 ramas de pequeños cambios de un proyecto de 300 Mb, y ahora me están ocupando 1200 Mb porque tengo que materializar las 4 ramas.

Las corramas solucionarían esto. También los enlaces duros (ver abajo).

2.1.4 BONUS forzar el uso de enlaces duros en las plataformas en las que es posible

Ahora (<30.m09.2009>):

  • bzr branch --hardlink no es la opción predeterminada. Debería ser bzr branch --no-hardlink lo opcional
  • al usar --hardlink salen errores extraños, como hardlinking working copy files is not currently supported in <WorkingTree6 of /home/dc/repoweb/minis3>

Los enlaces duros ahorran tanto espacio y velocidad, que obligar a trabajar sin ellos es desagradable. Bazaar debería negarse a trabajar sin enlaces duros, al menos en GNU y UNIX.

2.2 que el diff tenga colores

2.2.2 BONUS probar un primer parche para integrar cdiff en diff

Ver lista; no he de repetir ciertos errores: https://lists.ubuntu.com/archives/bazaar/2009q2/058552.html

2.2.2.1 IS leer colordiff.py

Vaya, entenderlo cuesta más de lo que esperaba. 10 min. era poco.

2.2.2.2 ver comando diff de bzr
2.2.2.3 estudiar compatibilidad
  • decidir dónde va cada cosa
    • terminal.py
2.2.2.4 leer correos de la lista y adaptar mi propuesta
2.2.2.5 integrar código de cdiff en diff, a lo bestia
2.2.2.6 refinar y mezclar las opciones
2.2.2.7 ajustar los parámetros usados
2.2.2.8 cambiar ayudas
2.2.2.9 preparar y enviar parche

2.3 BONUS el plugin gtk (bzr vis) no ha de usar bazaar.conf para guardar algo tan dinámico como el último tamaño de la ventana

Don't store window size in bazaar.conf https://bugs.launchpad.net/bugs/312720

2.4 IS al plugin qbzr se le ha estropeado el qdiff

  • CONCLUSIÓN escrita el <31.m03.2010 09:24>
    Lo arregló Gary rápidamente

qdiff: NameError: global name 'get_style_by_name' is not defined

https://bugs.launchpad.net/qbzr/+bug/551828

2.5 integración con Subversion

2.5.1 BONUS falla al cargar rama de Tikiwiki

2.6 integración con Git

2.6.1 IS peta al importar (git-import, en bzr-git) por sqlite3

  • CONCLUSIÓN escrita el <30.m03.2010 18:19>
    Jelmer lo corrigió muy rápido

sqlite3.InterfaceError in db.executemany: Error binding parameter 2 - probably unsupported type.

https://bugs.launchpad.net/bzr-git/+bug/551759

Pasa con todos repos.

2.6.2 BONUS sobreescribe demasiadas funcionalidades, hasta las básicas de desramar ramas de Bazaar

bzr-git prevents normal branching behaviour (ERROR: Push is not yet supported for bzr-git. Try dpush instead.)

https://bugs.launchpad.net/bzr-git/+bug/551792

2.7 IS bzrtools, está desactualizado (no hay 2.8.0)

<13.m04.2017> veo que desde 2014 no sale versión, la última es 2.6 de 2014. ∴ Cambiando yo nº de versión ya va.

3 problemas tenidos al desplegar y usar Bazaar

3.1 IS instalar bzr en HostMonster

  • CONCLUSIÓN escrita el <11.m02.2009 02:08>
    muy bonito. Queda empezar a usarlo y ver cómo va

Tiene 2.3. Quiero 2.4 ó 2.6. Mandar infrallo a donde toque

3.1.1 MALFAR Probar a usar Python 2.6

  • CONCLUSIÓN escrita el <11.m02.2009 00:42>
    muy difícil debido al time.so, que no está en HostMonster (es parte de dyn-load). Mejor si yo me instalo un Python en condiciones
3.1.1.1 error por _functools
danielcl@danielclemente.com [~/ut/bzr-1.12rc1]# ./bzr
Traceback (most recent call last):
  File "./bzr", line 79, in <module>
    import locale
  File "/usr/lib/python2.6/locale.py", line 15, in <module>
    import functools
  File "/usr/lib/python2.6/functools.py", line 10, in <module>
    from _functools import partial, reduce
ImportError: No module named _functools
danielcl@danielclemente.com [~/ut/bzr-1.12rc1]# 
3.1.1.2 error por: import site. Mal: uso python2.3
danielcl@danielclemente.com [~]# python -c "import site" -v
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/usr/lib/python2.6/site.py", line 150
    with f:
         ^
SyntaxError: invalid syntax
3.1.1.2.1 ¿? Pues sí que ha podido
danielcl@danielclemente.com [~]# python2.6 /usr/lib/python2.6/site.py
sys.path = [
    '/root/lib/python2.6',
    '/usr/lib/python2.6',
    '/usr/lib/python2.6/lib/python26.zip',
    '/usr/lib/python2.6/lib/python2.6',
    '/usr/lib/python2.6/lib/python2.6/plat-linux2',
    '/usr/lib/python2.6/lib/python2.6/lib-tk',
    '/usr/lib/python2.6/lib/python2.6/lib-old',
    '/usr/lib/python2.6/lib/python2.6/lib-dynload',
]
USER_BASE: '/home7/danielcl/.local' (doesn't exist)
USER_SITE: '/home7/danielcl/.local/lib/python2.6/site-packages' (doesn't exist)
ENABLE_USER_SITE: True
danielcl@danielclemente.com [~]# python2.6 -c "import site"
3.1.1.2.2 he de usar 2.6
danielcl@danielclemente.com [~]# python2.6 -c "import site" -v
danielcl@danielclemente.com [~]#
3.1.1.3 error por import time
danielcl@danielclemente.com [~]# python2.6 -c "import time" -v
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named time
danielcl@danielclemente.com [~]# 
3.1.1.3.1 dónde lo busca
stat("time", 0x7fff1a342dc0)            = -1 ENOENT (No such file or directory)
open("time.so", O_RDONLY)               = -1 ENOENT (No such file or directory)
open("timemodule.so", O_RDONLY)         = -1 ENOENT (No such file or directory)
open("time.py", O_RDONLY)               = -1 ENOENT (No such file or directory)
open("time.pyc", O_RDONLY)              = -1 ENOENT (No such file or directory)
stat("/usr/lib/python2.6/time", 0x7fff1a342dc0) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.6/time.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.6/timemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.6/time.py", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.6/time.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/root/lib/debug/usr/python2.6-bin/lib/python2.6/lib-dynload/time", 0x7fff1a342dc0) = -1 ENOENT (No such file or directory)
open("/root/lib/debug/usr/python2.6-bin/lib/python2.6/lib-dynload/time.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/root/lib/debug/usr/python2.6-bin/lib/python2.6/lib-dynload/timemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/root/lib/debug/usr/python2.6-bin/lib/python2.6/lib-dynload/time.py", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/root/lib/debug/usr/python2.6-bin/lib/python2.6/lib-dynload/time.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
futex(0x795680, FUTEX_WAKE, 1)          = 0
3.1.1.3.2 estar, está
/root/lib/debug/usr/python2.6-bin/lib/python2.6/lib-dynload

Pero es time.so.debug

/root/lib64/python2.3/lib-dynload/timemodule.so

3.1.1.3.2.1 copio los .so.debug a .so
danielcl@danielclemente.com [~/ut/lib/python-2.6/lib-dynload]# cp /root/lib/debug/usr/python2.6-bin/lib/python2.6/lib-dynload/* .
rename .so.debug .so *

Y en .bashrc:

PYTHONPATH=$PYTHONHOME:/home7/danielcl/ut/lib/python-2.6/lib-dynload

danielcl@danielclemente.com [~]# python2.6 -c "import time" -v
Speicherzugriffsfehler

3.1.1.3.2.2 pruebo con 2.3
export PYTHONPATH=$PYTHONHOME:/root/lib64/python2.3/lib-dynload/

Claro, no va:

danielcl@danielclemente.com [~]# python2.6 -c "import time" -v
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: /root/lib64/python2.3/lib-dynload/timemodule.so: undefined symbol: Py_InitModule4

3.1.2 IS instalar yo un Python normal

2.6.1. Lo compilo y va muy bien (aunque peta por el camino 2 veces, ignoradas).

3.1.2.1 probar Bazaar con este Python mío

3.1.3 IS instalar mi repo

3.1.3.1 problema: no me dejan conectar a DreamHost por SSH
danielcl@danielclemente.com [~/repoweb]# bzr branch bzr+ssh://dc@glass.dreamhost.com/home/dc/danielclemente.com/ preoficial
ssh: connect to host glass.dreamhost.com port 22: Connection timed out
bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)

Sí por el 80.

Pues hale, me queda sólo: bzr branch http://www.danielclemente.com/ preoficial que funciona.

3.1.4 metu mian branĉaron ĉe HostMonster

3.1.4.1 no puede llevar pues no encuentra bzr
: ~/desaweb/estructura ; bzr push bzr+ssh://danielcl@host296.hostmonster.com/home7/danielcl/repoweb/estructura
danielcl@host296.hostmonster.com's password: 
bash: bzr: command not found
bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
3.1.4.1.1 el mensaje de error es malo
3.1.4.1.2 esto sí que va
: ~/desaweb/estructura ; BZR_REMOTE_PATH=/home7/danielcl/bin/bzr time bzr push bzr+ssh://danielcl@host296.hostmonster.com/home7/danielcl/repoweb/estructura -Dhpss
danielcl@host296.hostmonster.com's password: 
Created new branch.                                                                                                           
HPSS calls: 108 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x84d30ac>
1.06user 0.15system 0:35.95elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
632inputs+88outputs (0major+5747minor)pagefaults 0swaps
3.1.4.2 tiel mi faris por
  • estructura
  • minis
  • ruido
  • ne oficial, ĉar ne necesas

Ĉiuj el ali. Facile kaj rapide

3.1.5 IS probar a bajar el repo entero en CPU107

Como no hay pull tendré que ir rama a rama. No cuesta tanto.

Iba a hacer…

: /w/repoweb ; bzr.dev pull bzr+ssh://danielcl@host296.hostmonster.com/home7/danielcl/repoweb/estructura

pero no, mejor esto (¡sí que hay pull de repositorio!):

: /w/repoweb ; BZR_REMOTE_PATH=/home7/danielcl/bin/bzr time bzr.dev multi-pull bzr+ssh://danielcl@host296.hostmonster.com/home7/danielcl/repoweb/

La pena es que no va, se queda colgado. Así que vuelvo a:

: /w/repoweb ; BZR_REMOTE_PATH=/home7/danielcl/bin/bzr time bzr.dev branch bzr+ssh://danielcl@host296.hostmonster.com/home7/danielcl/repoweb/estructura

Y hay que hacer lo mismo para: estructura minis preoficial ruido

¡Es muy lento! Quizás por la red. El primero tardó 1h6', los otros 3 ya 3'

Pero ya va.

3.1.6 IS publicar desde HM hasta DH

[glass:danielclemente.com]> BZR_REMOTE_PATH=/home7/danielcl/bin/bzr bzr pull bzr+ssh://danielcl@host296.hostmonster.com/home7/danielcl/repoweb/preoficial/

3.1.7 IS quitar rama preoficial y poner directamente la oficial en local pero apuntando a www.danielclemente.com realmente

  • CONCLUSIÓN escrita el <10.m05.2009 23:48>
    Pues me ha salido más o menos…

Así, un „bzr push“ local en la rama oficial ya serviría para actualizar la página. Esto hace la oficial distinta a las demás.

3.1.7.1 MALFAR antes necesito ponerme a usar mi web en mi página
  • CONCLUSIÓN escrita el <10.m05.2009 23:48>
    Ver abajo

Si no, me revierto al sistema de tener una rama „casi oficial“ en HostMonster que no lo es porque aún le falta ser pasada a DreamHost. Y ese intermediario es el que quiero evitar

3.1.7.1.1 No, no tengo ese problema

Pues puedo simplemente no tener esa rama. No existe nada „casi oficial“ más que las modificaciones locales que aún no he subido a la rama oficial de DreamHost.

3.1.7.2 cuidado, la preoficial tiene cosas no publicadas

<28.m04.2009 16:30> me dijo esto

: ~/repoweb/preoficial ; b push
Using saved push location: bzr+ssh://danielcl@host296.hostmonster.com/home7/danielcl/repoweb/preoficial/
running "ssh danielcl@host296.hostmonster.com /home7/danielcl/bin/bzr update "/home7/danielcl/repoweb/preoficial/""                                                               
 M  apuntes/catala.html
 M  apuntes/catala.t2t
All changes applied successfully.
Updated to revision 10.
This transport does not update the working tree of: bzr+ssh://danielcl@host296.hostmonster.com/home7/danielcl/repoweb/preoficial/. See 'bzr help working-trees' for more information.
Pushed up to revision 10.
3.1.7.3 pruebo a empujar directamente hacia la final (dreamhost), sin preoficial. A esta rama la llamo ofinial (oficial+final)
: ~/repoweb ; b branch bzr+ssh://dc@glass.dreamhost.com/home/dc/danielclemente.com/ ofinial

Muy rápido

3.1.8 IS hago la mezcla final de las 4 ramas hacia la ofinial

  • CONCLUSIÓN escrita el <11.m05.2009 00:25>
    ¡Ha ido mucho mejor de lo que pensaba! Todo como planeado, y rápido.

3.1.9 IS llevarla a DreamHost

  • CONCLUSIÓN escrita el <11.m05.2009 00:31>
    Fácil

De momento hago:

: ~/repoweb/ofinial ; time b push bzr+ssh://dc@glass.dreamhost.com/home/dc/danielclemente.com/
Password:            ] bzr+ssh <      0KB     0KB/s |                                                                                                         
This transport does not update the working tree of: bzr+ssh://dc@glass.dreamhost.com/home/dc/danielclemente.com/. See 'bzr help working-trees' for more information.
Pushed up to revision 18.

real	0m45.952s

Y luego:

[glass:danielclemente.com]> time bzr update
+N  cv/titjava-scwcd.jpg                                                                                                                                      
+N  hacer/index.html
+N  hacer/opciones.org
+N  hacer/temas.html
 M  cambios/cambios.xml
 M  cambios/index.html
 M  cambios/todos.html
 M  cambios/todos.xml
 M  cv/index.html
 M  cv/index.t2t
 M  cv/titnot.txt
 M  dislines/genera
 M  dislines/index.ca.html
 M  dislines/index.ca.t2t
 M  dislines/index.en.html
 M  dislines/index.en.t2t
 M  dislines/index.eo.html
 M  dislines/index.eo.t2t
 M  dislines/index.es.html
 M  dislines/index.es.t2t
 M  dislines/index.t2t
-D  hacer/index.html
RM  hacer/index.t2t => hacer/index.org
-D  hacer/opciones.t2t
-D  hacer/temas.html
RM  hacer/temas.t2t => hacer/temas.org
 M  linux/problems.t2t
 M  menu/menu.css
 M  ruido/index
 M  ruido/index.en.html
 M  ruido/index.html
 M  ruido/viejo/index.en.html
 M  ruido/viejo/index.html
All changes applied successfully.
Updated to revision 18.

real	0m4.839s
user	0m3.040s
sys	0m0.310s

3.1.10 lo que voy aprendiendo y decidiendo

  • la rama llamada ofinial será la versiós oficial y final de la página. Un push ahí la cambia (bueno, push-and-update o lo que sea)
  • claro, puedo ir haciendo cambios locales en esta rama; pero no podré compartir estos cambios a menos que los suba a ofinial
  • sólo tendré rama ofinial en los ordenadores en los que voy a editar los retoques pre-subidaa
  • no necesito rama preoficial
  • HostMonster es ahora un almacén de ramas; lo uso para sincronizar ali y CPU107
  • cualquier almacén local se trae las ramas de HostMonster, una por una, poniéndolas como URL de pull
  • la ofinial apunta a bzr+ssh://dc@glass.dreamhost.com/home/dc/danielclemente.com/ o al sitio donde tenga alojada yo la web realmente
  • como hay que ir con cuidado de no hacer push a ofinial por error, dejaré que pida contraseña siempre