Come determinare se svn: mergeinfo è corrotto e come posso risolvere il problema?

Question

Ho il sospetto che io abbia un mergeinfo corrotto ma non ne sono sicuro. Qualcuno sa come farei una determinazione e quali risorse sono là fuori per aiutare a risolvere i problemi?

Ecco il problema. Il mio team si è recentemente spostato sull'agile e utilizza i rami delle funzionalità (rami della storia) in cui team diversi lavorano contemporaneamente sulle stesse fonti. Mentre la storia raggiunge un alto stato di preparazione, la squadra si fonde con il tronco. Le fusioni richiedono giorni o settimane a causa di modifiche mancanti, modifiche impreviste e conflitti. Stiamo parlando di team di 5-10 persone e lo sforzo/churn sembra molto alto.

La gente usa il modello di questa fusione a) PULL - merge tronco-to-ramo, risolvere, prova, commettere b) PUSH - merge branch-to-tronco, risolvere, prova, commettere c) Ricreare ramo (o di solito creare un nuovo ramo della storia e abbandonare la vecchia poiché è stata completata)

Alla fine di questo ramo e tronco dovrebbero essere in allineamento.

problemi che stiamo vedendo:

1. modifiche non riportati durante tronco-to-unione tra rami presentarsi in successive
2. conflitti branch-to-tronco su svn: proprietà mergeinfo durante l'unione
3. file mancante, ma modifica locale sul nuovo file aggiunto nel ramo e inserito nel trunk
4. in arrivo + eliminazione locale (il file cancellato su trunk e branch mostra come conflitto)

(1) Non dovrebbe accadere. Il tiro dal ramo al tronco dovrebbe mettere i due in sincrono per tutte le modifiche già sul tronco. Le modifiche nella fusione da ramo a tronco sono le modifiche avvenute sul trunk. Quindi nella prima unione si sarebbero dovuti propagare alle diramazioni, ma non l'hanno fatto. Ciò indica la corruzione nei dati di mergeinfo che "nascondono" le modifiche del trunk.

(2) Non dovrebbe accadere. SVN dovrebbe gestire le modifiche nel tracciamento unione. Ciò indica anche la corruzione nei dati di mergeinfo

(3) Non dovrebbe accadere. Questo è il caso di un nuovo file aggiunto sul ramo. Dovrebbe apparire come un nuovo file aggiunto al trunk. Ciò indica anche la corruzione nei dati di informazioni di fusione.

(4) Credo che questo sia un bug SVN e che non possiamo risolvere questo problema. Comunque se questo fosse il nostro unico problema sarei felice

Siamo attualmente sul server svn 1.5.x con i client che usano svn 1.6.xe svn + ssh per la connessione. Abbiamo in programma di passare all'ultima e più grande SVN poiché alcune correzioni potrebbero influire sui nostri problemi.

Tuttavia, sembra sicuro che i nostri dati di mergeinfo siano errati.

• Unisce che non evidenziare tutte le variazioni
• conflitti in fusione di proprietà mergeinfo

Eventuali buoni posti per me per iniziare la ricerca?

Answer 1

Ho fatto alcuni esperimenti con la ramificazione/unione SVN e ho scoperto che ci sono alcune situazioni in cui l'unione non funziona, ad esempio le modifiche dal trunk vengono sovrascritte. Quindi, se continui a utilizzare SVN per i rami delle funzionalità, sarai nel mondo del dolore.

Ho fatto esperimenti simili con git e non ho trovato un modo per ottenere l'unione non corretta. Se passare a git potrebbe essere accettabile dal team/management, consiglio vivamente di usarlo.

Answer 2

Abbiamo avuto problemi simili a causa di circostanze simili e in gran parte li abbiamo risolti.

Quello principale è questo:

Se si uniscono nel vostro ramo dal tronco dopo la creazione ramo, è necessario tronco bandiera con il ramo commit (usando svn merge --record-only), altrimenti quando si prova a reintegrarsi nel tronco per cercare di unire il tronco del tronco al ramo.

Questo, ovviamente, finisce per annullamento di modifiche al tronco dopo che la trunk-> ramo tardi impegnarsi, tende a provocare enormi conflitti (in particolare i conflitti albero se è stato creato un nuovo file o directory in tronco), ecc

Così il nostro processo è o tronco mai sincronizzazione in un ramo dopo che è stato creato (funziona bene per brevi rami vissuto), o per effettuare le seguenti operazioni:

• ramo b da tronco
• impegna a tronco e ramo
• reintegrarsi tronco in filiale e si impegnano (risolvere i conflitti ma per il resto fare nessuna modifica, anche per la compilazione)
• immediatamente fare uno svn merge --record solo del tronco-to-branch commettere revisione
• risolve altri problemi con la ramo e continuare lo sviluppo
• reintegro dal ramo al tronco una volta fatto.

Ho trovato: http://www.collab.net/community/subversion/articles/merge-info.html utile mentre stavo lavorando a quello che stavamo facendo male.