Re: aerb "file has been altered" errors after removing files in branch
Calvin Webster <[email protected]> Wed, 27 Apr 2016 09:11:57 -0400
| Newsgroups | gmane.comp.version-control.aegis.user |
|---|---|
| Message-ID | <1461762717.14245.182.camel@klink> |
--===============4828111183463000177==
Content-Type: multipart/alternative; boundary="=-up+eYDu1fI7T0+gvw6ls"
--=-up+eYDu1fI7T0+gvw6ls
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
On Mon, 2016-04-25 at 12:08 -0400, Calvin Webster wrote:
> On Mon, 2016-04-25 at 15:08 +0200, Ralf Fassel wrote:
>
> > A different approach would be to temporarily alter the project config
> > to go directly to being_reviewed instead of awaiting_review and see
> > whether this makes a difference. It could be that only 'aerb' has a
> > problem with this step, and that other steps are ok.
>
>
>
> That's an excellent idea Ralf! I'll give that a shot. Thanks!
Unfortunately, this didn't help. Neither did fiddling with the
fingerprints.
> > As to hacking aegis' database...
> > Myself, I would make a backup of the aegis project directory, then
> > search all files for the filename in question, then simply remove
> > every section which refers to that file. This way aegis would never
> > have known the file.
> >
> > cd /path/to/aegis/projectdir
> > find info -type f | xargs grep FILENAME
> >
> > Eg:
> > info/change/0/004.branch/0/000.branch/0/020.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.branch/0/010.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.branch/3/333.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.branch/3/387.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.branch/3/330.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.branch/3/366.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.branch/1/198.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.branch/4/418.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.branch/7/701.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.branch/7/706.fs: file_name = "include/si++/hdsys.h";
> > info/change/0/004.branch/0/000.fs: file_name = "include/si++/hdsys.h";
> >
> > This breaks the ability to recreate changes from the past which still
> > had the file in question, but since you said you don't care...
>
>
>
> I think this is the way I'll end up handling this issue for now. I
> think it may be simplest for me to go ahead and remove all traces of
> these misplaced derived files at this point. I found that removing
> both the stanzas containing the base file and path
> (CymSOUND93/bin/buildinfo) in the 15053.fs file eliminated the
> original error. One stanza was for the "aemv" and the other for the
> "aerm". However, as I suspected, another error took its place citing
> another file that had previously been moved and removed.
>
> I just hope it ends here, in this branch. If I can get through this I
> definitely would never again add derived files to an Aegis project. I
> suspect this was the main cause when Aegis config was set to retain
> derived files. I'll also be cautious about using "aemv" and "aerm" on
> the same files in the same branch.
This was how I ended up clearing the log jamb. It was tedious and
time-consuming because there was no simple way to automate the process.
Fortunately, most of the derived files were in separate directories.
[root@pegasus2 ~]# cd /archive/trainer/av8b93/av8b93
[root@pegasus2 av8b93]# find info/ -type f -exec grep -l cymsound93 {} \;
info/change/0/023.fs
info/change/0/023.branch/111/11117.fs
info/change/0/023.branch/111/11117.pfs
info/change/0/023.branch/111/11117.branch/0/004.fs
...
info/change/0/023.branch/111/11117.branch/0/003.fs
info/change/0/023.branch/150/15023.pfs
info/trunk.fs
[root@pegasus2 av8b93]#
[root@pegasus2 av8b93]# vi info/change/0/023.fs
/cymsound93
Search for sections pertaining to removed files and delete them. Very
time consuming...
In the end, however, I was able to review and integrate all the branches
up to the project root.
./Cal
--=-up+eYDu1fI7T0+gvw6ls
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
<BR>
On Mon, 2016-04-25 at 12:08 -0400, Calvin Webster wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
On Mon, 2016-04-25 at 15:08 +0200, Ralf Fassel wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
A different approach would be to temporarily alter the project config
to go directly to being_reviewed instead of awaiting_review and see
whether this makes a difference. It could be that only 'aerb' has a
problem with this step, and that other steps are ok.
</PRE>
</BLOCKQUOTE>
<PRE>
</PRE>
<B>That's an excellent idea Ralf! I'll give that a shot. Thanks!</B><BR>
</BLOCKQUOTE>
<BR>
<B>Unfortunately, this didn't help. Neither did fiddling with the fingerprints.</B><BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
As to hacking aegis' database...
Myself, I would make a backup of the aegis project directory, then
search all files for the filename in question, then simply remove
every section which refers to that file. This way aegis would never
have known the file.
cd /path/to/aegis/projectdir
find info -type f | xargs grep FILENAME
Eg:
info/change/0/004.branch/0/000.branch/0/020.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.branch/0/010.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.branch/3/333.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.branch/3/387.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.branch/3/330.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.branch/3/366.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.branch/1/198.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.branch/4/418.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.branch/7/701.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.branch/7/706.fs: file_name = "include/si++/hdsys.h";
info/change/0/004.branch/0/000.fs: file_name = "include/si++/hdsys.h";
This breaks the ability to recreate changes from the past which still
had the file in question, but since you said you don't care...
</PRE>
</BLOCKQUOTE>
<PRE>
</PRE>
<B>I think this is the way I'll end up handling this issue for now. I think it may be simplest for me to go ahead and remove all traces of these misplaced derived files at this point. I found that removing both the stanzas containing the base file and path (CymSOUND93/bin/buildinfo) in the 15053.fs file eliminated the original error. One stanza was for the "aemv" and the other for the "aerm". However, as I suspected, another error took its place citing another file that had previously been moved and removed.</B><BR>
<BR>
<B>I just hope it ends here, in this branch. If I can get through this I definitely would never again add derived files to an Aegis project. I suspect this was the main cause when Aegis config was set to retain derived files. I'll also be cautious about using "aemv" and "aerm" on the same files in the same branch.</B><BR>
</BLOCKQUOTE>
<BR>
<B>This was how I ended up clearing the log jamb. It was tedious and time-consuming because there was no simple way to automate the process. Fortunately, most of the derived files were in separate directories.</B><BR>
<BR>
<PRE>
[<A HREF="mailto:root@pegasus2">root@pegasus2</A> ~]# <B>cd /archive/trainer/av8b93/av8b93</B>
[<A HREF="mailto:root@pegasus2">root@pegasus2</A> av8b93]# <B>find info/ -type f -exec grep -l cymsound93 {} \;</B>
info/change/0/023.fs
info/change/0/023.branch/111/11117.fs
info/change/0/023.branch/111/11117.pfs
info/change/0/023.branch/111/11117.branch/0/004.fs
...
info/change/0/023.branch/111/11117.branch/0/003.fs
info/change/0/023.branch/150/15023.pfs
info/trunk.fs
[<A HREF="mailto:root@pegasus2">root@pegasus2</A> av8b93]#
[<A HREF="mailto:root@pegasus2">root@pegasus2</A> av8b93]# <B>vi info/change/0/023.fs</B>
</PRE>
<BR>
/cymsound93<BR>
<BR>
<B>Search for sections pertaining to removed files and delete them. Very time consuming...</B><BR>
<BR>
<B>In the end, however, I was able to review and integrate all the branches up to the project root.</B><BR>
<BR>
<B>./Cal</B><BR>
<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>
--=-up+eYDu1fI7T0+gvw6ls--
--===============4828111183463000177==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQWVnaXMtdXNl
cnMgbWFpbGluZyBsaXN0CkFlZ2lzLXVzZXJzQGxpc3RzLmF1dWcub3JnLmF1Cmh0dHBzOi8vbGlz
dHMuYXV1Zy5vcmcuYXUvbGlzdGluZm8vYWVnaXMtdXNlcnMK
--===============4828111183463000177==--