Bug 95177 - support lock feature
support lock feature
Status: RESOLVED FIXED
Product: versioncontrol
Classification: Unclassified
Component: Subversion
6.x
All All
: P1 with 37 votes (vote)
: 7.1
Assigned To: issues@versioncontrol
issues@versioncontrol
: PLAN
: 115435 129564 135466 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-11 14:19 UTC by abs
Modified: 2011-06-09 13:50 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description abs 2007-02-11 14:19:40 UTC
Current subversion module doesn't support lock feature. How about if NetBeans
support lock feature.

I think Eclipse's subversion plug-in(Subclipse) is good example of this.
Comment 1 Peter Pis 2007-09-13 12:42:25 UTC
*** Issue 115435 has been marked as a duplicate of this issue. ***
Comment 2 Tomas Stupka 2008-03-07 18:44:28 UTC
*** Issue 129564 has been marked as a duplicate of this issue. ***
Comment 3 Tomas Stupka 2008-05-21 07:45:01 UTC
*** Issue 135466 has been marked as a duplicate of this issue. ***
Comment 4 tprochazka 2008-09-28 08:42:35 UTC
Will be supported also svn:needs-lock property?
Comment 5 akiliyevich 2009-04-03 09:32:24 UTC
Please, add the following two classes in org.netbeans.modules.subversion.client.cli.commands

public class LockCommand extends SvnCommand {

    private final File[] files;
    private final String message;
    private final boolean force;

    public LockCommand(File[] files, String message, boolean force) {
        this.files = files;
        this.message = message;
        this.force = force;
    }

    @Override
    protected int getCommand() {
        return ISVNNotifyListener.Command.LOCK;
    }

    @Override
    public void prepareCommand(Arguments arguments) throws IOException {
        arguments.add("lock");
        if (force) {
            arguments.add("--force");
        }
        arguments.addMessage(message);
        arguments.addFileArguments(files);
        setCommandWorkingDirectory(files);
    }
}

public class UnlockCommand extends SvnCommand {

    private final File[] files;
    private final boolean force;

    public UnlockCommand(File[] files, boolean force) {
        this.files = files;
        this.force = force;
    }

    @Override
    protected int getCommand() {
        return ISVNNotifyListener.Command.UNLOCK;
    }

    @Override
    public void prepareCommand(Arguments arguments) throws IOException {
        arguments.add("unlock");
        if (force) {
            arguments.add("--force");
        }
        arguments.addFileArguments(files);
        setCommandWorkingDirectory(files);
    }
}

And make the following changes in org.netbeans.modules.subversion.client.cli.CommandlineClient,
instead of throw new UnsupportedOperationException("Not supported yet.");

    public void lock(File[] files, String message, boolean force) throws SVNClientException {
        LockCommand cmd = new LockCommand(files, message, force);
        exec(cmd);
    }

    public void unlock(File[] files, boolean force) throws SVNClientException {
        UnlockCommand cmd = new UnlockCommand(files, force);
        exec(cmd);
    }

I have just test it, it's worked:
SvnClient client = Subversion.getInstance().getClient(file);
client.lock(new File[]{file}, "test lock", false);
Comment 6 dusty 2009-08-05 13:46:54 UTC
This feature would be very welcome, I also need it and currently I must lock/unlock files via commandline svn
Comment 7 gionny 2009-09-09 21:58:35 UTC
The feature would be very appreciated by me and by a lot of collegues of mine that are using Netbeans, too.
Comment 8 jordanorc 2010-02-14 12:44:20 UTC
This feature is really important!

How is the progress to add this feature?

This bus was opened in 2007 and we have no response yeat!

Thank's
Comment 9 Tomas Stupka 2010-02-18 11:31:13 UTC
due to the current resource situation in the vcs team this issue won't be impleneted in 6.9
Comment 10 thomasv 2010-03-26 09:56:19 UTC
(In reply to comment #5)
> Please, add the following two classes in
> org.netbeans.modules.subversion.client.cli.commands
> public class LockCommand extends SvnCommand {
>     private final File[] files;
>     private final String message;
>     private final boolean force;
>     public LockCommand(File[] files, String message, boolean force) {
>         this.files = files;
>         this.message = message;
>         this.force = force;
>     }
>     @Override
>     protected int getCommand() {
>         return ISVNNotifyListener.Command.LOCK;
>     }
>     @Override
>     public void prepareCommand(Arguments arguments) throws IOException {
>         arguments.add("lock");
>         if (force) {
>             arguments.add("--force");
>         }
>         arguments.addMessage(message);
>         arguments.addFileArguments(files);
>         setCommandWorkingDirectory(files);
>     }
> }
> public class UnlockCommand extends SvnCommand {
>     private final File[] files;
>     private final boolean force;
>     public UnlockCommand(File[] files, boolean force) {
>         this.files = files;
>         this.force = force;
>     }
>     @Override
>     protected int getCommand() {
>         return ISVNNotifyListener.Command.UNLOCK;
>     }
>     @Override
>     public void prepareCommand(Arguments arguments) throws IOException {
>         arguments.add("unlock");
>         if (force) {
>             arguments.add("--force");
>         }
>         arguments.addFileArguments(files);
>         setCommandWorkingDirectory(files);
>     }
> }
> And make the following changes in
> org.netbeans.modules.subversion.client.cli.CommandlineClient,
> instead of throw new UnsupportedOperationException("Not supported yet.");
>     public void lock(File[] files, String message, boolean force) throws
> SVNClientException {
>         LockCommand cmd = new LockCommand(files, message, force);
>         exec(cmd);
>     }
>     public void unlock(File[] files, boolean force) throws SVNClientException {
>         UnlockCommand cmd = new UnlockCommand(files, force);
>         exec(cmd);
>     }
> I have just test it, it's worked:
> SvnClient client = Subversion.getInstance().getClient(file);
> client.lock(new File[]{file}, "test lock", false);

While waiting for this feature to be included in a netbeans release, I thought it was a great idea to include your lines, and recompile the module. I did, and It seems to work fine.
However, Im not sure how to get the menu items for lock/unlock into the context menu. Do you, or anyone else perhaps know how to acomplish this?
Comment 11 Tomas Stupka 2010-03-26 14:32:26 UTC
o.n.m.subversion.Annotator.getActions(...) could be a good entry point

- create your own action. Subclass from ContextAction if it's supposed to be context sensitive - e.g. IgnoreAction or StatusAction are simple enough and should give you an idea what to do. 
- add it to the list returned in getActions(...) - once for main menu and once for the context menu
Comment 12 jcookist 2011-01-22 23:52:40 UTC
i need this feature
Comment 13 wmorris20 2011-02-24 16:46:25 UTC
What's the new milestone for this feature now that 6.9 has passed?
Comment 14 tghasemi 2011-03-28 23:11:29 UTC
I really need this feature ! any updates on it ? would it be included in the NetBeans 7 ?
Comment 15 Ondrej Vrabec 2011-03-29 07:01:01 UTC
> would it be included in the NetBeans 7?
No. Due to limited resources we have we do not plan to implement this feature any time soon, contribution and patches are welcome.
Comment 16 thomasv 2011-03-29 07:18:58 UTC
So how long do we have to wait?!
It is a simple issue, could be solved really easy, and we've been waiting 4 years already!
Could I tell my grand children this is something they can expect to be blessed with? :)
Comment 17 artisan 2011-03-29 07:42:58 UTC
As NB is use the system svn, files can be locked at command line too.

I went for another IDE in the end. :-(

Sorry.
Comment 18 Marian Mirilovic 2011-03-29 08:13:18 UTC
anebuzelsky, 
33 votes - candidate for NB 7.1 I hope .
Comment 19 Ondrej Vrabec 2011-04-18 12:22:56 UTC
Some notes about the feature: http://netbeans.org/projects/versioncontrol/pages/Svn_lock. Look at the wiki page and let us know if you think something should look or be approached differently
Comment 20 dusty 2011-04-18 12:41:08 UTC
@ovrabec
I find your proposal sound, particularly the "on demand locking", which I find particularly useful!
Comment 21 narve 2011-05-10 13:12:41 UTC
The proposal sounds very good, indeed it is way overkill for our needs. The On demand locking should be default off, if you ask me. There usually is a good reason for setting the "needs-lock" property. Furthermore, don't contact the server unless requested - most files are not locked and we don't need more lag in Netbeans :)
Comment 22 Ondrej Vrabec 2011-05-27 07:11:32 UTC
ok, time for implementation
Comment 23 Ondrej Vrabec 2011-05-27 13:56:31 UTC
fix: http://hg.netbeans.org/core-main/rev/a5b5ff38bb1e
Comment 24 Ondrej Vrabec 2011-05-27 14:01:45 UTC
(In reply to comment #23)
> fix: http://hg.netbeans.org/core-main/rev/a5b5ff38bb1e
text annotations for now
Comment 25 Quality Engineering 2011-05-28 12:17:54 UTC
Integrated into 'main-golden', will be available in build *201105280401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/a5b5ff38bb1e
User: Ondrej Vrabec <ovrabec@netbeans.org>
Log: Issue #95177 - support lock feature
annotate labels for locked files
Comment 26 Ondrej Vrabec 2011-05-31 15:59:13 UTC
fix: http://hg.netbeans.org/core-main/rev/91fadfee156f
Comment 27 Quality Engineering 2011-05-31 19:27:15 UTC
Integrated into 'main-golden', will be available in build *201105310954* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/c10219dde10f
User: Ondrej Vrabec <ovrabec@netbeans.org>
Log: Issue #95177 - support lock feature
lock and unlock actions
Comment 28 Quality Engineering 2011-06-01 13:16:25 UTC
Integrated into 'main-golden', will be available in build *201106010401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/c10219dde10f
User: Ondrej Vrabec <ovrabec@netbeans.org>
Log: Issue #95177 - support lock feature
lock and unlock actions
Comment 29 Quality Engineering 2011-06-02 20:36:07 UTC
Integrated into 'main-golden', will be available in build *201106021001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/c10219dde10f
User: Ondrej Vrabec <ovrabec@netbeans.org>
Log: Issue #95177 - support lock feature
lock and unlock actions
Comment 30 Ondrej Vrabec 2011-06-09 10:42:39 UTC
Could anyone check it in http://bits.netbeans.org/download/trunk/nightly/latest/ and give us some feedback before it's too late and 7.1 is out?
Comment 31 narve 2011-06-09 12:53:06 UTC
Tested on my system: 

Product Version: NetBeans IDE Dev (Build 201106080600)
Java: 1.6.0_24; Java HotSpot(TM) 64-Bit Server VM 19.1-b02
System: Windows 7 version 6.1 running on amd64; Cp1252; no_NO (nb)

Works smoothly, including the editor switching to/from readonly-mode nicely. 

One issue: No errors/messages are shown if it fails - neither as an error dialog (preferrable), or as a message in the IDE status bar. In my case it failed because of an authentication issue. When I tried commit'ing instead, I got the authentication dialog (as I should). After authenticating it worked. 

Well done! Please add some error handling and it is good for 7.1!
Comment 32 Ondrej Vrabec 2011-06-09 13:15:21 UTC
(In reply to comment #31)
> neither as an error dialog (preferrable)
i am against, raising a dialog for a background task (that is not triggered by an explicit user action) is IMO a bad idea. Especially to users who might not expect it, this could be really troublesome. For example in case you are not connected to network.
> or as a message in the IDE status bar
That's an option, plus can be logged in the output window
Comment 33 narve 2011-06-09 13:23:58 UTC
(In reply to comment #32)
> (In reply to comment #31)
> > neither as an error dialog (preferrable)
> i am against, raising a dialog for a background task (that is not triggered by
> an explicit user action) is IMO a bad idea. Especially to users who might not
> expect it, this could be really troublesome. For example in case you are not
> connected to network.
> > or as a message in the IDE status bar
> That's an option, plus can be logged in the output window

I agree, sort of, but this was not a background task, it was triggered by me choosing the "Lock" command. (Can this be started as background task?? I'm against)

However, I didn't check the output window, so I checked it now, and it doesn't make sense: 

==[IDE]== 09.jun.2011 14:47:43 Locking Files...
lock -m "i need lock" myfile.xml
Autorisasjonen feilet
svn: User canceled dialog

But I didn't get any authentication dialog!? (Btw: "Autorisasjonen feilet" means "Authentication failed", don't know why it shows in Norwegian)
Comment 34 Ondrej Vrabec 2011-06-09 13:50:39 UTC
I thought you were talking about on-demand locking. But i can see now what the problem is. I don't know why, but our external svn client library does not throw an Authentication exception when lock/unlock fails (while it does for all other commands). So we cannot react properly to this with raising the authentication dialog. See the commented ex: http://subclipse.tigris.org/source/browse/subclipse/trunk/svnClientAdapter/src/javahl/org/tigris/subversion/svnclientadapter/javahl/AbstractJhlClientAdapter.java?view=diff&r1=1794&r2=1795&pathrev=4898
This is indeed a bug and we should deal with it, i filed a bug: #199309


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo