Re: rollback to previous revision
Hello, > How to rollback of a file or folder to previous revision? svn merge -rHEAD:PREV TARGET Andreas
Re: rollback to previous revision
Hi, Hello, How to rollback of a file or folder to previous revision? svn merge -rHEAD:PREV TARGET Andreas Or svn up -r [file/folder] if by "rollback" you mean to get an older revision of a file/folder instead of reverting changes done to the file. -- Regards, Stefan Hett, Developer/Administrator EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany Tel: +49 2405 4239970, www.egosoft.com Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
RE: rollback to previous revision
Maybe I didn't describe it clearly. I mean to rollback on the repository instead of the working copy. If a user checked in a "wrong" file, system administrator/project manager needs to rollback the file to the previous revision on the repository. -Original Message- From: Stefan Hett [mailto:ste...@egosoft.com] Sent: Monday, February 22, 2016 6:28 AM To: users@subversion.apache.org Subject: Re: rollback to previous revision Hi, > Hello, > >> How to rollback of a file or folder to previous revision? > svn merge -rHEAD:PREV TARGET > > Andreas Or svn up -r [file/folder] if by "rollback" you mean to get an older revision of a file/folder instead of reverting changes done to the file. -- Regards, Stefan Hett, Developer/Administrator EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany Tel: +49 2405 4239970, www.egosoft.com Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
Re: rollback to previous revision
Hi, Maybe I didn't describe it clearly. I mean to rollback on the repository instead of the working copy. If a user checked in a "wrong" file, system administrator/project manager needs to rollback the file to the previous revision on the repository. Then go with Andreas' suggestion and do a commit of the revert afterwards (aka: svn ci [...]). Afterwards the revision (or just the changes in one of the files/folders done in that revision) is reverted. P.S. pls don't top post. Regards, Stefan
RE: (unknown)
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: zondag 14 februari 2016 15:35 > To: Michal Matyl > Cc: users@subversion.apache.org > Subject: Re: (unknown) > > Michal Matyl wrote on Thu, Feb 11, 2016 at 10:19:02 +: > > The example is about a simple branch merging with default settings and > > a classic conflict situation, no fancy features or complex > > trunk-to-branch back merging, so I belive simple prose description of > > the problem is enough. > > The prose did not suffice: I would not have understood the problem > without the attachment. The preferred way to describe a bug is by > a script that reproduces it. > > For future reference, we provide template scripts at: > https://subversion.apache.org/docs/community- > guide/issues.html#reporting-bugs > (fourth paragraph) > > > First developer creates branch-01 and inserts few lines into existing > > file. Another developer creates branch-02 and makes exactly the same > > changes as first developer, i.e. inserts the same lines with the same > > content. The only difference in the second's developer branch is > > whitespace change (space/tab doesn't matter) in a line preceding > > inserted lines. > > > > You are describing a merge where > > * The difference between the OLD and MINE is: > > Index: branches/branch-01/test_file.txt > > == > = > --- branches/branch-01/test_file.txt(revision 3) > +++ branches/branch-01/test_file.txt(revision 4) > @@ -1,6 +1,9 @@ > A > B > C > +D > +E > +F > J > K > L > \ No newline at end of file > > * The difference between OLD and THEIRS is: > > Index: branches/branch-02/test_file.txt > > == > = > --- branches/branch-02/test_file.txt(revision 6) > +++ branches/branch-02/test_file.txt(revision 7) > @@ -1,6 +1,9 @@ > A > B > -C > + C > +D > +E > +F > J > K > L > \ No newline at end of file > > * There are no local mods. > > That merge results in: > > Index: trunk/test_file.txt > > == > = > --- trunk/test_file.txt (revision 7) > +++ trunk/test_file.txt (revision 8) > @@ -1,9 +1,12 @@ > A > B > -C > + C > D > E > F > +D > +E > +F > J > K > L > \ No newline at end of file > > Yes, I also think that is a bug: a text conflict should have been > flagged. I just reviewed most of the code that is responsible for this behavior... and I have to conclude it works 'as designed'. 1) We determine the changes on both sides. * On one side we see a replacement of line 'C', by a different set of tokens. * And on the other side we see an insertion of a set of tokens after 'C'. (This code is in subversion/diff/lcs.c) 2) Then we combine the changes of both sides. * We can apply the first change as there are no overlapping regions * We can apply the second change as there no overlapping regions (This code is in subversion/diff/diff3.c) In our very abstract implementation things work as intended... so now we have to determine how we want to fix things. -> back to design phase. I have a working patch that determines that these changes touch each other and then marks them as conflict, but that still doesn't produce the kind of conflict that you would really want here. And I'm not sure In the optimal case we would flag one conflict containing both changes *as one*, but that will take more work. Note that the 'whitespace' (noted in original report) is completely unrelated to this issue. Our diff code works with tokens, while the whitespace is handled in the tokenizer. I can easily reproduce this issue without any whitespace changes. Bert
Removing a directory gets stuck
Hello! I use TortoiseSVN (1.9.3) on Windows 7 and observe the effect that deleting (svn rm or move) a directory about once in four attempts fails with something along "could not remove directory because it was not empty". I suspect that the virus scanner stands in the way, because when I look the directory is empty, and a cleanup process almost always succeeds. Can the directory removal be made more robust (like: if it fails and shouldn't, just wait a second and retry, and *then* complain) or be de-interlaced from the database operation, removing the entry in the working copy, closing the database and after that issuing the remove and rmdir commands on the file system? Mit freundlichen Grüßen Dr. Hartmut Niemann Siemens AG MO MLT LM EN CCI 1 Werner-von-Siemens-Str. 67 91052 Erlangen, Deutschland Tel.: +49 9131 7-34264 Fax: +49 9131 7-26254 mailto:hartmut.niem...@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
RE: (unknown)
[Moving thread to dev@s.a.o from users@]
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: maandag 22 februari 2016 13:21
> To: 'Daniel Shahaf' ; 'Michal Matyl'
>
> Cc: users@subversion.apache.org
> Subject: RE: (unknown)
>
> I just reviewed most of the code that is responsible for this behavior... and
> I
> have to conclude it works 'as designed'.
>
> 1) We determine the changes on both sides.
> * On one side we see a replacement of line 'C', by a different set of tokens.
> * And on the other side we see an insertion of a set of tokens after 'C'.
> (This code is in subversion/diff/lcs.c)
>
> 2) Then we combine the changes of both sides.
> * We can apply the first change as there are no overlapping regions
> * We can apply the second change as there no overlapping regions
> (This code is in subversion/diff/diff3.c)
>
> In our very abstract implementation things work as intended... so now we
> have to determine how we want to fix things. -> back to design phase.
>
>
> I have a working patch that determines that these changes touch each other
> and then marks them as conflict, but that still doesn't produce the kind of
> conflict that you would really want here. And I'm not sure
>
> In the optimal case we would flag one conflict containing both changes *as
> one*, but that will take more work.
>
>
>
> Note that the 'whitespace' (noted in original report) is completely unrelated
> to this issue. Our diff code works with tokens, while the whitespace is
> handled in the tokenizer. I can easily reproduce this issue without any
> whitespace changes.
I completed the patch to a form, where I like the result.
[[
Index: subversion/libsvn_diff/diff3.c
===
--- subversion/libsvn_diff/diff3.c (revision 1731660)
+++ subversion/libsvn_diff/diff3.c (working copy)
@@ -320,16 +320,17 @@ svn_diff_diff3_2(svn_diff_t **diff,
suffix_lines, subpool);
lcs_ol = svn_diff__lcs(position_list[0], position_list[2], token_counts[0],
token_counts[2], num_tokens, prefix_lines,
suffix_lines, subpool);
/* Produce a merged diff */
{
svn_diff_t **diff_ref = diff;
+svn_diff_t *diff_last = NULL;
apr_off_t original_start = 1;
apr_off_t modified_start = 1;
apr_off_t latest_start = 1;
apr_off_t original_sync;
apr_off_t modified_sync;
apr_off_t latest_sync;
apr_off_t common_length;
@@ -429,16 +430,17 @@ svn_diff_diff3_2(svn_diff_t **diff,
is_modified = lcs_om->position[0]->offset - original_start > 0
|| lcs_om->position[1]->offset - modified_start > 0;
is_latest = lcs_ol->position[0]->offset - original_start > 0
|| lcs_ol->position[1]->offset - latest_start > 0;
if (is_modified || is_latest)
{
+svn_boolean_t add_diff = TRUE;
modified_length = modified_sync - modified_start;
latest_length = latest_sync - latest_start;
(*diff_ref) = apr_palloc(pool, sizeof(**diff_ref));
(*diff_ref)->original_start = original_start - 1;
(*diff_ref)->original_length = original_sync - original_start;
(*diff_ref)->modified_start = modified_start - 1;
@@ -450,26 +452,47 @@ svn_diff_diff3_2(svn_diff_t **diff,
if (is_modified && is_latest)
{
svn_diff__resolve_conflict(*diff_ref,
&position_list[1],
&position_list[2],
num_tokens,
pool);
}
-else if (is_modified)
+else if (is_modified
+ && (!diff_last
+ || diff_last->type != svn_diff__type_diff_latest))
{
(*diff_ref)->type = svn_diff__type_diff_modified;
}
-else
+else if (is_latest
+ && (!diff_last
+ || diff_last->type != svn_diff__type_diff_modified))
{
(*diff_ref)->type = svn_diff__type_diff_latest;
}
+else
+ {
+/* We have a latest and a modified region that touch each
other,
+ but not directly change the same location. Create a single
+ conflict region to properly mark a conflict, and to ease
+ resolving. */
+diff_last->type = svn_diff__type_conflict;
+diff_last->original_length += (*diff_ref)->original_length;
+diff_last->modified_length += (*diff_ref)->modified_length;
+diff_last->latest_length += (*diff_ref)->latest_length;
-diff_ref = &(*diff_ref)->next;
+
Re: Removing a directory gets stuck
On 22.02.2016 14:26, Niemann, Hartmut wrote: > > Hello! > > > > I use TortoiseSVN (1.9.3) on Windows 7 and observe the effect that > deleting (svn rm or move) a directory > > about once in four attempts fails with something along “could not > remove directory > > because it was not empty”. > > > > I suspect that the virus scanner stands in the way, because when I > look the directory is empty, and > > a cleanup process almost always succeeds. > > > > Can the directory removal be made more robust (like: if it fails and > shouldn’t, just wait a second and retry, > > and *then* complain) > This is what Subversion already does. Windows virus scanners are notoriously flaky, buggy and broken; we've had Windows-specific retry logic in the code almost from day one because of that, and the back-off and retry can be longer than one second. The fault is squarely at the door of virus scanner developers; they're supposed to be invisible to the user but the majority do not preserve filesystem semantics. > or be de-interlaced from the database operation, removing the entry in > the > > working copy, closing the database and after that issuing the remove > and rmdir commands on the > > file system? > This would be a great way to randomly break working copies. The on-disk state and the database contents have to be in sync; we go to a lot of trouble to make sure they are. Decoupling database changes from filesystem changes would pretty much guarantee that /any/ problem, transient or otherwise, with the disk or filesystem would leave the working copy irretrievably broken. -- Brane
