Hi Jaap, hi all.

Le mardi 14 octobre 2008 à 12:11 +0200, Jaap Karssenberg a écrit :

> Hmm, this will be tricky, because it has to match the exact
> localization of the installed subversion version. Problem is that
> although svn prints an error it does not return an error code I can
> detect.
> 
> Is there an alternative svn command to query existence of the url ? Or
> should I just call mkdir and assume the location exists when it fails
> ?
> 
> Action item #2: fix detection of existence of repository directory
> 

Don't know, maybe using the list sub-command.

Say the user enters an url : URL

To check if this it exists, you can make :

        svn list URL

If the url exists, the sub-command will list the corresponding content :

- If the url is a repo, it could be something like this :

        project1/
        project2/
        etc.

- If the url is a folder in a repo, it will output the content of the
folder :

        page1
        page2
        folder1/
        etc.

- If the url doesn't exist, the sub-command will output a message like
that :

        svn: [whatever] 'URL' [whatever]

So, this message could be matched against a regex, depending exclusively
on the url entered by the user.

> > Note : url field
> > ..................
> 
> Correct, but I put it there just to hint the user that an full URL is 
> expected.
> 

Right. 

> 
> The wanted behavior of revert is that the specified version is rolled
> back and committed to the repository as a new version. Will it work
> that way with this command ? What is the difference / advantage over
> using svn cat ?

Well, i clearly don't know if 'svn update' is more efficient than 'svn
cat', i never use it : each time i have to revert a file to a previous
version, i use svn update.

With 'svn update foo.txt -r X', the foo.txt file in your working copy
(the zim notebook) is replaced by the foo.txt you commited into the
repository at revision X.

Use case with a foo.txt file

- edit -> commit -> foo.txt r1
- edit -> commit -> foo.txt r2
- edit -> commit -> foo.txt r3

1. You edit the file but you make mistakes : you want to come back to
the last committed version :

        svn revert foo.txt

You have now foo.txt r3 in your working copy.
(bzr equivalent : bzr revert foo.txt)

2. You edit the file but you make mistakes, and you see that there's
also mistakes in the last commit (r3), so you want to revert the file to
a previous version :

        svn update -r 2 foo.txt

Now, foo.txt in your working copy is an exact copy of foo.txt r2
(bzr equivalent : bzr revert -r 2 foo.txt)

If you commit without editing (commit -> foo.txt r4), foo.txt r4 will be
the same as foo.txt r2.

I think it's the behaviour you want to implement...

There is no equivalent of the uncommit command in bzr (as i know).

> > About focus on windows
>
> I have seen this before, but only on windows. Probably a combination
> of gtk and or specific window manager.
> 
> Please open a bug report for this and include first part of the zim -V
> output were it gives the gtk version numbers etc.

I also see this kind of behaviour with gtk apps on Windows (Geany).

I opened a bug report.

Thanks.

regards,

-- 
Rui Nibau <[EMAIL PROTECTED]>
Développeur web, rédacteur scientifique
http://www.omacronides.com
http://www.framasoft.net



_______________________________________________
Mailing list: https://launchpad.net/~zim-wiki
Post to     : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Reply via email to