mboost-dp1
Accidental: svn rm -- Need SVN help...
Så kom jeg til at add en folder som jeg ikke skulle, så jeg kørte en svn rm, og vil nu igen adde folderen, som nu er tømt for ubrugelige filer, mejn nu siger den at det må jeg ikke da filerne er scheduled for deletion...
Hvordan reverter jer den rm commando...
-En ren revert duer ikke, da jeg har nogen ændringer i filerne siden sidst jeg ikke vil have fjernet...??
----- Jeg har ikke comitted endnu..
Hvordan reverter jer den rm commando...
-En ren revert duer ikke, da jeg har nogen ændringer i filerne siden sidst jeg ikke vil have fjernet...??
----- Jeg har ikke comitted endnu..
#4
Indtil du laver en "svn revert" på filerne der er scheduleret til at blive slettet, vil dette ikke ændres.
Mit foreslag er det at du bruger kommandoen "svn diff" til at få fat i dine tekstuelle modifikationer (altså ikke tree-modifications, etc.), put dem i en fil. Du kan evt. "pipe" outputtet til en fil, og grep'e file deletions væk (jeg antager du bruger linux/unix eller har cygwin på wnidows).
Derefter laver du en "svn revert", så din WC er tilbage på HEAD-revisionen af det der ligger i dit repository.
Til sidst bruger du så "svn patch" kommandoen til at flette dine ændringer ind i filerne.
Det er mit bedste bud.
Indtil du laver en "svn revert" på filerne der er scheduleret til at blive slettet, vil dette ikke ændres.
Mit foreslag er det at du bruger kommandoen "svn diff" til at få fat i dine tekstuelle modifikationer (altså ikke tree-modifications, etc.), put dem i en fil. Du kan evt. "pipe" outputtet til en fil, og grep'e file deletions væk (jeg antager du bruger linux/unix eller har cygwin på wnidows).
Derefter laver du en "svn revert", så din WC er tilbage på HEAD-revisionen af det der ligger i dit repository.
Til sidst bruger du så "svn patch" kommandoen til at flette dine ændringer ind i filerne.
Det er mit bedste bud.
Er SVN et af den slags versionsstyringssystemer hvor serveren gemmer oplysninger om hvad en klient er i gang med at ændre, men ikke har commitet endnu? Jeg husker lignende opførsel fra Perforce. Det var da meget praktisk at man kunne snage i hvad ens kollegaer var i gang med at ændre. Men enormt upraktisk at den slags oplysninger åbenbart krævede urimeligt mange serverresurser og administratorerne derfor jævnligt slettede klienter. Og det betød så også at man ikke bare kunne kopiere de lokale filer for at have et nyt checkout med samme version og samme ændringer.Corholio (6) skrev:Indtil du laver en "svn revert" på filerne der er scheduleret til at blive slettet, vil dette ikke ændres.
jeg undskylder:
bla bla bla....
Jeg gjorde det at jeg gemte alle de filer jeg havde andetsteds, og comittede, så lagde jeg dem tilbage fter en svn update, og addede dem jeg skulle bruge igen , og så kom jeg tilbage dertil hvor jeg kunne comitte de filer jeg havde ændret og ikke alle de mellem-filer mit build havde producerert......
bla bla bla....
Jeg gjorde det at jeg gemte alle de filer jeg havde andetsteds, og comittede, så lagde jeg dem tilbage fter en svn update, og addede dem jeg skulle bruge igen , og så kom jeg tilbage dertil hvor jeg kunne comitte de filer jeg havde ændret og ikke alle de mellem-filer mit build havde producerert......
#7
Nej, Subversion virker på en sådan måde at man laver et checkout (working copy), modificerer filerne lokalt og laver derefter et check-in. Serveren ved dermed intet om hvad der foregår på klient-maskinen, kun modifikationer på filer / tree modifikationer der bliver checked-in.
Nej, Subversion virker på en sådan måde at man laver et checkout (working copy), modificerer filerne lokalt og laver derefter et check-in. Serveren ved dermed intet om hvad der foregår på klient-maskinen, kun modifikationer på filer / tree modifikationer der bliver checked-in.
kasperd (10) skrev:Så forstår jeg ikke hvordan det kan være et problem at filerne er "scheduled for deletion".Corholio (9) skrev:Serveren ved dermed intet om hvad der foregår på klient-maskinen
Det er et problem med SVN klienten at man ikke kan fjerne "scheduled for deletion" igen. Hvis man har godt styr på de filer svn laver, burde man godt kunne fjerne det selv med en tekst- eller hexeditor.
Men der er så intet der forhindrer at man gør følgende:Emil Melgaard (12) skrev:Det er et problem med SVN klienten at man ikke kan fjerne "scheduled for deletion" igen.
1. Lav et nyt checkout
2. Kør svn diff kommando på gamle checkout og patch på det nye checkout
3. Slet det gamle checkout
Skridt 2 kunne evt. erstattes med at blot flytte de ændrede filer fra det gamle checkout til det nye checkout.
Hvis man har lavet en ændring i klienten uden at commite, så skal den selvfølgelig kunne revertes uden man behøver starte en ny klient og uden at der nogensinde kommer spor efter den ændring på serveren. Det gælder uanset hvilken type ændring der er tale om. Hvis ikke det kan lade sig gøre, så er det en bug. At starte en ny klient er bare et workaround.
Det giver en underlig commit log, og kan potentielt ødelægge historien.kasperd (13) skrev:Skridt 2 kunne evt. erstattes med at blot flytte de ændrede filer fra det gamle checkout til det nye checkout.
Det er bedre at patche.
... men hele diskussionen beviser bare at folk burde bruge git/hg i stedet for SVN.
svn vil da aldrig kunne se forskel på de to. Det vil blot se at en fil er ændret. Om det er sket med patch kommandoen, ved at flytte en fil derind, eller ved brug af en editor kan det ikke se.Windcape (14) skrev:Det giver en underlig commit log, og kan potentielt ødelægge historien.
Det er bedre at patche.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund