Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
app-portage/cfg-update - troubleshooting
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Wed Jan 04, 2006 12:23 am    Post subject: app-portage/cfg-update - troubleshooting Reply with quote

******************************************************************************

NOTE TO ALL USERS:

After 5 years I'm finally looking for someone capable of fully adopting cfg-update as I do not have the time to properly support it anymore. I will fix all remaining bugs in week 31 and write some documentation to enable someone else to continue developing it further...

Send me a private message if you're interested in adopting cfg-update.

Regards,

Stephan van Boven

[11-JUL-2008]
******************************************************************************




I have submitted the new cfg-update-1.8.0-r1 ebuild for testing.
It will be added to portage (masked ~x86) very soon.
If you have questions, tips, suggestions or want to discuss bugs or
minor problems, you can use this thread.

For more details see: app-portage/cfgupdate - installation instructions

(I decided to start a new thread because the old support thread
was getting a bit to big...)

_________________
When all else fails, read the manual...
Registered Linux User #340626


Last edited by xentric on Sun Nov 23, 2008 12:17 am; edited 8 times in total
Back to top
View user's profile Send private message
tightcode
Tux's lil' helper
Tux's lil' helper


Joined: 23 Mar 2004
Posts: 110

PostPosted: Wed Jan 04, 2006 6:27 pm    Post subject: Reply with quote

Happy New Year xentric

I am happy to see a new version of cfg-update, the changelist seems very interesting and the addition of a bash version of the phphelper and the external config file both were commonly requested features (even if the *helper files may not be necessary anymore as you noted).
Congratulations !!

I have one small bug to report. I have just updated and when running cfg-update --help, I get the output twice (condensed to not take up too much room in the forum):

Code:
[13:02:00][root@xxxxx<xx.xxx.xxx.xx:/var/tmp]# cfg-update --help

USAGE     cfg-update [flags] [runmode]                        (version 1.8.0)

FLAGS
[...]
For more info, type: man cfg-update


USAGE     cfg-update [flags] [runmode]                        (version 1.8.0)

FLAGS
[...]
For more info, type: man cfg-update

[13:02:32][root@xxxxx<xx.xxx.xxx.xx:/var/tmp]#


Another small request: Would you be able to set the output of cfg-update which is seen during the emerge process to match the phphelper script, so that it is colored and looks like other emerge related output, something along the lines of replacing:

Code:
________________________________________________________________________________

cfg-update 1.8.0 : Building checksum index... (takes a few seconds)  done!
________________________________________________________________________________


with

Code:
>>> cfg-update: Building checksum index... (takes a few seconds)  done!
>>> cfg-update: Done, continuing with emerge.


By colorise I actually just "bolded" "cfg-update:" so that regardless of the console background color it should look alright. You dont have to break it into two lines like that but I figured since I was reducing from 4 lines I could take up 2 and it would still be 50% savings.

Thanks again for the continued support and I look forward to testing this new version!

Cheers,

TightCode
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Wed Jan 04, 2006 7:23 pm    Post subject: Reply with quote

tightcode wrote:
I have one small bug to report. I have just updated and when running cfg-update --help, I get the output twice
Thanks, this will be fixed in the -r2 version.
Quote:
Another small request: Would you be able to set the output of cfg-update which is seen during the emerge process to match the phphelper script, so that it is colored and looks like other emerge related output
Sounds good... I'll make it look like regular emerge output, just like your phphelper script.
Quote:
Thanks again for the continued support and I look forward to testing this new version!

Have fun with it, and thanks for your input!
_________________
When all else fails, read the manual...
Registered Linux User #340626
Back to top
View user's profile Send private message
radfoj
Guru
Guru


Joined: 31 Dec 2004
Posts: 490
Location: Tísek, Czech Republic

PostPosted: Thu Jan 05, 2006 3:44 pm    Post subject: Reply with quote

Hi xentric,

its nice how you listen to us - users - and how you improve this tool.

Today, I would like to know one thing - how cfg-update works with emerging in two or more consoles at the same time. I am using cfg almost for one year, but never did it. Mainly, becouse I wasnt sure, if its safe. Here is one example, to understand my question:

I start updating of 10 packages. At the begginig, cfg-update create checksum and emerge begin. After 4 updated packages (+some new config in /etc were created) I decide to emerge somethig small in another console. What will happen? How cfg-update handles this paralel emerges? Should some problems occuer?

Thanks
Back to top
View user's profile Send private message
mgorbach
n00b
n00b


Joined: 03 Aug 2005
Posts: 51

PostPosted: Thu Jan 05, 2006 4:31 pm    Post subject: Reply with quote

shouldn't the alias be in bashrc not bash_profile?
I often do my updates using su, and this does not create a login shell so bash_profile doesn't execute ... right?
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Thu Jan 05, 2006 7:07 pm    Post subject: Reply with quote

radfoj wrote:
I start updating of 10 packages. At the begginig, cfg-update create checksum and emerge begin. After 4 updated packages (+some new config in /etc were created) I decide to emerge somethig small in another console. What will happen? How cfg-update handles this paralel emerges? Should some problems occur?


Cfg-update will check the portage logs to see what the most recent emerged
package is. It then checks it's checksum-index, the first line contains the name
of the package that was emerged last when the checksum-index was updated.
If there is a difference it means that new packages have been installed after
the last indexing. So cfg-update will start looking in the protected directories for
._cfg0000_ files. If ._cfg0000_ files exist in the protected directories, indexing
is skipped... if they do not exist it will update the checksum-index with the MD5
hashes from the CONTENTS files.

So if portages stores the hashes before putting the file in the protected dirs,
there is a window of oppurtunity where things can go wrong. But the worst case
is that the second instance of cfg-update uses the MD5 hash of the new file
instead of the MD5 hash of the current file to determine if the current file has
been changed. If this happends, cfg-update will show the file as being modified
(while it's not) resulting in a forced manual merge in the GUI tool instead of an
automatic update.

The conclusion is that you don't have to worry about it... it's perfectly safe!
_________________
When all else fails, read the manual...
Registered Linux User #340626


Last edited by xentric on Thu Jan 05, 2006 7:19 pm; edited 1 time in total
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Thu Jan 05, 2006 7:14 pm    Post subject: Reply with quote

mgorbach wrote:
shouldn't the alias be in bashrc not bash_profile?
I often do my updates using su, and this does not create a login shell so bash_profile doesn't execute ... right?

Thanks for pointing this out... I've googled around and found this.
Lot's of pages say that both .bashrc and .bash_profile can be used for user aliases,
but non-login shells like xterms do not read .bash_profile upon login. So .bashrc is
the best choice to put the alias in... You are absolutely right :D
I will change this in version 1.8.0-r3
_________________
When all else fails, read the manual...
Registered Linux User #340626
Back to top
View user's profile Send private message
verbbis
n00b
n00b


Joined: 12 Mar 2005
Posts: 3

PostPosted: Fri Jan 06, 2006 1:12 pm    Post subject: Reply with quote

Not sure if it's something I did, but seems that in some cases the merged file loses permissions given on the original one. That caused some problems for me after updating init-scripts. The merged script didn't have it's executable-bit set.
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Fri Jan 06, 2006 6:12 pm    Post subject: Reply with quote

verbbis wrote:
Not sure if it's something I did, but seems that in some cases the merged file loses permissions given on the original one. That caused some problems for me after updating init-scripts. The merged script didn't have it's executable-bit set.

Hey this is weird. This was an issue with one of the old versions, but I
fixed it long ago. I will check it tonight!
_________________
When all else fails, read the manual...
Registered Linux User #340626
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Sun Jan 08, 2006 1:29 am    Post subject: Reply with quote

verbbis wrote:
The merged script didn't have it's executable-bit set.

Did you disable backups in /etc/cfg-update.conf ?
If that's the case, I may have found the cause of your problem.
BTW, what version are you using?
_________________
When all else fails, read the manual...
Registered Linux User #340626
Back to top
View user's profile Send private message
mgorbach
n00b
n00b


Joined: 03 Aug 2005
Posts: 51

PostPosted: Sun Jan 08, 2006 6:55 am    Post subject: Reply with quote

thanks for the response on my bashrc question.
unfortunately, this still wont allow cfg-update to do its thing when a command like sudo emerge ... is run, because a sudo command does not source any env setup files ... i dont think. Oh well, at least i can use su then normally.

also ... is there any way i can change the text cfg-update prints when updateing its index to be only one line and colored? can i modify the script or maybe change a wrapper to do this?

PS. i had the exact same issue when merging an initscript, /etc/init.d/clock. the executable bit was not set on the resulting (merged) file. as you can imagine this causes problems when booting/shutting down the system.
Back to top
View user's profile Send private message
verbbis
n00b
n00b


Joined: 12 Mar 2005
Posts: 3

PostPosted: Mon Jan 09, 2006 12:54 am    Post subject: Reply with quote

xentric wrote:
verbbis wrote:
The merged script didn't have it's executable-bit set.

Did you disable backups in /etc/cfg-update.conf ?
If that's the case, I may have found the cause of your problem.
BTW, what version are you using?

Thanks for the reply. The config file I'm using is the default one, and backups are enabled. I was able to reproduce the phenomenon, however. Just altered the year from an init-script header, re-emerged baselayout and ran
Code:
sudo cfg-update -u -t /usr/bin/sdiff

chose the right column and accepted changes.
I wasn't using X at the time. The version I'm using is cfg-update-1.8.0-r1
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Mon Jan 09, 2006 6:44 am    Post subject: Reply with quote

verbbis wrote:
Thanks for the reply. The config file I'm using is the default one, and backups are enabled. I was able to reproduce the phenomenon, however. Just altered the year from an init-script header, re-emerged baselayout and ran
Code:
sudo cfg-update -u -t /usr/bin/sdiff

chose the right column and accepted changes.
I wasn't using X at the time. The version I'm using is cfg-update-1.8.0-r1

I have fixed the bug. I still have to test some situations and fix some other things
but will try to get version 1.8.0-r2 out as soon as possible. Thanks for the info!
_________________
When all else fails, read the manual...
Registered Linux User #340626
Back to top
View user's profile Send private message
tightcode
Tux's lil' helper
Tux's lil' helper


Joined: 23 Mar 2004
Posts: 110

PostPosted: Mon Jan 09, 2006 5:30 pm    Post subject: Reply with quote

This would probably be classified more as a wish than a bug and has been something I was manually changing since the first version I tried. I am only mentioning it now since the new use of a configuration file gives an acceptable solution to the problem.

On line 552 & 553 of /usr/bin/cfg-update you hardcode the Qt style of xxdiff. Could you either add in the config file a XXDIFF_OPTS where one could modify the style to suit their system or somehow detect the currently used style and apply it ? I have just in the past gone and hardcoded my existing style (baghira) but there could be an easier way (ie: autodetection)

Thanks again and I must say after a few days of usage I am really liking the 1.8.x branch !

Cheers,

TightCode
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Wed Jan 11, 2006 10:12 pm    Post subject: Reply with quote

Just submitted an update for cfg-update (1.8.0-r2)
I have fixed the following things:

1. It now correctly sets the executable bit after updating if the original file was executable.
2. It does not restore the MD5 checksum when restoring backups as that caused the file to be handled as unmodified even when it was modified because the wrong checksum was restored in the index... I found out that the original checksum can't be determined so I completely took this out. Restore files will be handled as modified files, forcing a manual update regardless of the true state of the file.
3. Added a variable to the cfg-update.conf that controls the GUI style of xxdiff.
4. Changed the indexing message to better match the style of emerge and added a setting to cfg-update.conf to controle the GUI style of xxdiff.
5. Removed the --fix option and moved the check for /root/.bashrc to the --on option. This has to be run manually after installation (because it changes a file in /root/)
6. Removed kdiff3 from RDEPEND in ebuild. Added text to the install instructions that a user can install different tools separately. xxdiff will remain the default tool.
7. Fixed reading of enable_backups setting from cfg-update.conf which was broken.
8. Fixed double printing of --help output
9. The .bash_profile and .Xdefaults file are no longer included in the tarball because putting the alias in .bashrc should be sufficient for using cfg-update.

Thanks for your feedback guys!
_________________
When all else fails, read the manual...
Registered Linux User #340626
Back to top
View user's profile Send private message
Devport
Guru
Guru


Joined: 15 Dec 2004
Posts: 361

PostPosted: Sat Jan 21, 2006 7:03 am    Post subject: Reply with quote

Hi, I really love cfg-update and I really hope this will be the default for gentoo systems one day.

But that indexing upsets me.

I regularly emerge things and the indexing wastes a good amount of time on my 2GHz AMD 64. Is it really neccessary ? I would prefer one indexing when configuration files are actually being updated and not after each merge. Usually several packages are emerged before an update to the config-files happens. I don't see a reason why that indexing would have to happen after every single package that has been emerged - cause the merge of other packages doesn't touch the changes to the other packages config files - and even if it would they were cumulative.
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Sat Jan 21, 2006 1:47 pm    Post subject: Reply with quote

Devport wrote:
I regularly emerge things and the indexing wastes a good amount of time on my 2GHz AMD 64. Is it really neccessary ?


There are several solutions:

I have included wrapperscripts to prevent indexing on non-installing usage of the emerge command and thus delays indexing until new programs...
Change the alias in /root/.bashrc to:
alias emerge='emerge_with_indexing_for_cfg-update_bashhelper'
OR
alias emerge='emerge_with_indexing_for_cfg-update_phphelper'

OR disable automatic indexing with "cfg-update -off" and update the index manually when you want with "cfg-update -i". The worst that can happen is that you'll have to update files manually while they could have been updated automatically if the checksum-index was up-to-date.

But can you also give me an idea of how long indexing takes on your machine?
I only have a Pentium3 850Mhz laptop with 256Mb RAM and a relatively slow 2,5" HD and about 400 installed packages. Indexing never takes longer than 10 seconds on my machine:
Code:
root@gentoo 852MHz 49C linux # time cfg-update --index
>>> cfg-update-1.8.0-r4 : Building checksum index... (takes a few seconds)  done!

real    0m7.026s
user    0m2.705s
sys     0m0.764s

So I would really like to know what causes the extraordinary long indexing delays on some systems!
If you would like to help me figure out what's wrong, you can do the following (as root):
Code:
# locale
# env
# df -a
# mount
# emerge info
# time portageq config_protect
# time cat /var/db/pkg/*/*/CONTENTS | grep '^obj ' | awk '{ print $2"  "$3 }' > /tmp/testindex && rm -rf /tmp/testindex
And please post the output of these commands...

In the meantime I'll start thinking about optimizing the timing of indexing for the next version of cfg-update.
_________________
When all else fails, read the manual...
Registered Linux User #340626
Back to top
View user's profile Send private message
Devport
Guru
Guru


Joined: 15 Dec 2004
Posts: 361

PostPosted: Sat Jan 21, 2006 2:01 pm    Post subject: Reply with quote

xentric wrote:
... OR disable automatic indexing with "cfg-update -off" and update the index manually when you want with "cfg-update -i". The worst that can happen is that you'll have to update files manually while they could have been updated automatically if the checksum-index was up-to-date.

Is there any difference in behaviour at all if I disable automatic indexing and do cfg-update -i + cfg-update -u after some merges ? If not wouldn't it be better to disable automatic indexing and instead make cfg-update check before any action like cfg-update -u if the index is up to date and if not then do the indexing before updating ?

xentric wrote:
But can you also give me an idea of how long indexing takes on your machine?
I only have a Pentium3 850Mhz laptop with 256Mb RAM and a relatively slow 2,5" HD and about 400 installed packages. Indexing never takes longer than 10 seconds on my machine

It only takes approximatly up to 5 seconds on my system - but it is still way too long if it happens every now and then.
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Sat Jan 21, 2006 3:28 pm    Post subject: Reply with quote

Devport wrote:
Is there any difference in behaviour at all if I disable automatic indexing and do cfg-update -i + cfg-update -u after some merges ? If not wouldn't it be better to disable automatic indexing and instead make cfg-update check before any action like cfg-update -u if the index is up to date and if not then do the indexing before updating ?

I think you are right... except that cfg-update needs to update it's checksum-index as soon as possible after all config files have been updated and before new packages are being emerged.

I can simply put it at the end of the updating session... if cfg-update detects that all updates have been done it can simply update the checksum index. Which will only take 5-20 seconds at the end of an update session that completes all updates. This makes the alias for emerge obsolete and prevents delays during normal emerge usage.

A small voice in the back of my head keeps saying I used the emerge alias for a reason, but I can't figure out what would cause problems if we do this as I described above. So I'll start testing a new version of cfg-update which uses this method for updating the checksum-index.

Thanks for your input! I'll keep you updated with the results.
_________________
When all else fails, read the manual...
Registered Linux User #340626
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Sat Jan 21, 2006 7:08 pm    Post subject: Reply with quote

The little voice was right though... but it has very low impact:

Let's say you finish an updating session and the checksum index is updated. After this you emerge a new package foo-1.0 which uses a new config file /etc/foo. Then before you do any updating sessions a new version of foo is released and you decide to install foo-2.0. Now you get /etc/._cfg0000_foo but cfg-update doesn't know about /etc/foo because it has been installed after the last checksum-index update.
This makes cfg-update determine the file to be a custom file because it can't find an entry for /etc/foo in the checksum-index. This forces a manual update while it could have been an automatic update! But to put this in perspective, this situation would be rare if the user updates his config files before emerging new packages, as he/she should.

Advantages of the new, index updating without emerge alias, method:
++ no index checking/updating delays during emerge commands
++ no need for portage logging (PORT_LOGDIR) to determine if an index update is necessary or not
++ no need for an alias for emerge in /root/.bashrc
+ installation will require less fiddling...
Disadvantages new method:
-- there's no (easy/quick/fast) way to check if an index update is necessary or not
- you'll need a forced index update after cfg-update -u sessions (if all ._cfg0000_ files are gone)
- can't determine modification state of files that have been installed+updated after the last indexing

So the current method is more complete as it catches all possible autoupdates. But the advantages of the new method far outweigh the disadvantages. I'm going to implement this in the next version as the default way to update the index but I will keep support for the alias in there to prevent transition problems and to provide users with a choice.

When the "update_files" subroutine is finished it will call the "done" subroutine which checks if there are any ._cfg????_files left on the system.
If there are still updates on the system, it will prompt the user to run "cfg-update -u" again untill all updates are dealt with... and exits.
If it doesn't find any, it will check if there is an alias for emerge.
If the alias for emerge is enabled it skips the index update as the alias will take care of the index... and exits.
If no alias is found it will force an index update... then exits
_________________
When all else fails, read the manual...
Registered Linux User #340626
Back to top
View user's profile Send private message
iliah
n00b
n00b


Joined: 01 Aug 2004
Posts: 42
Location: Russia Moscow

PostPosted: Tue Jun 20, 2006 10:47 am    Post subject: Reply with quote

cfg-update get broken after emerging =virtual/libstdc++3.3 with output:

"Nested quantifiers in regex; marked by <-- HERE in m/virtual:libstdc++ <-- HERE -3.3:20060620-095632.log/ at /usr/bin/cfg-update line 759. ..."

unmerging virtual/libstdc++ didn't help :(
Back to top
View user's profile Send private message
radfoj
Guru
Guru


Joined: 31 Dec 2004
Posts: 490
Location: Tísek, Czech Republic

PostPosted: Tue Jun 20, 2006 10:52 am    Post subject: Reply with quote

get rid of libstdc++ log file in /var/log/portage or where you have set PORT_LOGDIR variable ... and pull back libstdc++ package
Back to top
View user's profile Send private message
ppurka
Advocate
Advocate


Joined: 26 Dec 2004
Posts: 3256

PostPosted: Thu Jul 20, 2006 5:25 pm    Post subject: gvimdiff with cfg-update Reply with quote

I tried fooling your script by giving it the path to a script that I named as xxdiff :D The script parses your arguments and uses vimdiff/gvimdiff. It is as follows:
Code:
#!/bin/bash
# for xxdiff, $@ = --style <style> --resource <resource> <diff1> <diff2> -M <diff3.merge>
FILES=;
until [[ -z "$1" ]]; do
    case $1 in
    --style)    shift; ;;
    --resource) shift; ;;
    -M)    FILES="$FILES $2"; cp ${2%\.*} ${2} || exit 1; shift; ;; # copy original file to .merge
    /*)         FILES="$FILES $1"; ;;
    *)          ;;
    esac
    shift;
done
# need to pass nofork to gvimdiff so that it does not detach from shell
[[ -z "$DISPLAY" ]] && vimdiff $FILES || gvimdiff --nofork $FILES
However, I haven't yet understood how I can get gvimdiff to show the .merge file separately, on a horizontal split (instead of a vertical split), just like in that xxdiff screenshot. Can some vim guru suggest some way of achieving that?
Back to top
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Fri Jul 21, 2006 6:07 am    Post subject: Re: gvimdiff with cfg-update Reply with quote

ppurka wrote:
However, I haven't yet understood how I can get gvimdiff to show the .merge file separately, on a horizontal split (instead of a vertical split), just like in that xxdiff screenshot. Can some vim guru suggest some way of achieving that?


I found a good tutorial for merging with vimdiff
And I've got this working with cfg-update 8)

I'm glad that I've played around with vi in my early linux days... hahaha
All I needed was some vim command codes for navigating around in the files:

ctrl-ww = change cursor to the other window
do = obtain the diff from the other window
dp = put the diff in the other window
zo = unfold text without diffs
zc = fold text without diffs
]c = jump to next diff
[c = jump to previous diff
i = insert mode for text editing
:diffupdate = recalculate diffs
:qa! = close vimdiff without saving
:wqa = save changes and close vimdiff
ESC = if you don't know in what mode vimdiff is...

Just wondering what the undo/redo commands are :?:

When the merge tool (vimdiff in this case) exits, cfg-update looks for the /etc/foo.merge file. If it doesn't find that file it checks if the current configuration file /etc/foo has been changed (MD5 checksum). If it has changed, cfg-update concludes that you have saved the merged result as /etc/foo and so it can complete the update by saving the backups /etc/._old-cfg_foo and /etc/._new-cfg_foo and removing /etc/._cfg0000_foo.

Because vimdiff stores an empty /etc/foo.merge file even when you have only looked at the files and haven't changed a thing, I need to force users to save the merged result as /etc/foo. So I have to make the right window "unmodifiable and read-only" to prevent accidental modification of the update file.

I have tested this method, and with the above information I was able to complete the update without problems...
(couldn't figure out how 3-way merging is done in vimdiff)

Just insert the following two lines in subroutine launch_tool (line 547) in /usr/bin/cfg-update:
Code:
    if  ($_[1] =~ /\/vimdiff$|^vimdiff$/   )                          { $cmd = "$_[1] -c 'saveas $file1' -c next -c 'setlocal nomodifiable readonly' -c prev $file1 $file2 --nofork $debug"; }
    if  ($_[1] =~ /\/gvimdiff$|^gvimdiff$/ )                          { $cmd = "$_[1] -c 'saveas $file1' -c next -c 'setlocal nomodifiable readonly' -c prev $file1 $file2 --nofork $debug"; }

then use "cfg-update -u -t vimdiff" to test it... (or set "MERGETOOL=vimdiff" permanently in /etc/cfg-update.conf)
_________________
When all else fails, read the manual...
Registered Linux User #340626


Last edited by xentric on Thu Aug 24, 2006 6:08 pm; edited 4 times in total
Back to top
View user's profile Send private message
ppurka
Advocate
Advocate


Joined: 26 Dec 2004
Posts: 3256

PostPosted: Fri Jul 21, 2006 2:24 pm    Post subject: Reply with quote

I don't think vimdiff can, by itself, make a 3-way diff. However, I discovered a command yesterday:
Code:
comm -1 -2 file1 file2 > file1.merge
which strips out the lines from file1 and file2 which are not in common (and strips out some other common lines too :( ). That might be used to create a file1.merge and then pass on that file1.merge to vimdiff. But, I think it would probably be a ugly modification to your script.

However, many many thanks for providing a means of providing a 2-way diff through vimdiff!! Will test it out as soon as I get some time.

I didn't know about some of those commands that you have provided (diffupdate, for eg. zo, zc are general fold commands [to easily create a fold, press V, then use j/k or arrow keys to select text, and then type zf] ). To enable multiple undo's and redo's in vim, use :set nocompatible (nocompatible => not vi mode) and then 'u' and 'CTRL-r' are used for undo and redo respectively.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum