subversive-dev

[subversive-dev] Announcing the release of EasySVN

easysvn@xxxxxxx (EasySVN) — Thu, 17 May 2012 15:47:21 GMT

Assembla is announcing the release of EasySVN, a free, open-source Subversion client with unique features to make Subversion easier to use. We just posted a 1.0 release for Windows and a beta release for Macintosh. You can download them from http://assemb.la/EasySVN

EasySVN adds the following capabilities:

• Automatic update and commit mode. When this is selected, your subversion working copy acts like Dropbox, gDrive, Skydrive, and related cloud file systems. It has the advantage of being open source and portable, so you have many options for the location and security of files. Because it’s Subversion, it handles big files and repositories. This mode is useful for graphical files from designers, and other files that aren’t code.

• Simplified operations to checkout, invite, and create repositories on the Assembla hosting system. For example, selecting “Share on Assembla” on any local directory will create a repository, add the files, and commit them, in one operation.

• Free backend storage. Select “Share on Assembla” and you immediately get one of our free subversion repositories.

The Windows release builds on TortoiseSVN, the most popular Windows client. Assembla worked with the TortoiseSVN team and with joint team member Stefan Fuhrmann to design the background replication features.

The Macintosh release is integrated into the Finder. It builds on the once-popular SCPlugin open source client, which did not work after OSX version 10.6 because Apple disabled Finder plugins. The Assembla team re-engineered it to use the Apple’s new Services structure. They also updated it to Subversion 1.7, added a *nix port of the automatic update and commit, and added the Assembla integration.

The automatic update and commit operations are also available in a Linux command line version with source code.

If you are interested in contributing to these projects, please go to http://www.assembla.com/spaces/easysvn-tortoise

[subversive-dev] [ANN] SVNKit 1.7.4 is released!

alexander.kitaev@xxxxxxx (Alexander Kitaev) — Fri, 13 Apr 2012 12:02:18 GMT

Hello All,

We are glad to announce that long awaited SVNKit 1.7.4 is released and
is available for download at http://svnkit.com/download/ page.

Please note, that in order to avoid user's confusion, we've decided to
follow Subversion version numbering, and this first version of SVNKit
which is compatible with Subversion 1.7 has 1.7.4 as a version number,
not 1.7.0.

Major new features of the new SVNKit 1.7.4 are:

- SVNKit 1.7.4 supports both old 1.6 and new 1.7 working copies and
repositories.
- New command-style API (org.tmatesoft.svn.core.wc2), that one may
find more convenient than the old one.
- SVNKit 1.7.4 is binary compatible with the older versions, existing
code will continue to work with the new version.
- SVNKit 1.7.4 includes new JavaHL (org.apache.subversion.javahl)
implementation.
- Java 1.5 or newer is required

We would appreciate your feedback and questions on our mailing list,
or to support@xxxxxxxxxx
You may also submit issues directly at http://issues.tmatesoft.com/

Thanks!

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Safe Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

[subversive-dev] blog post: Subversion 1.7 - Zippy, but should you upgrade?

igor.vinnykov@xxxxxxx (Igor Vinnykov) — Fri, 02 Dec 2011 20:07:15 GMT

Greetings,

SVN 1.7 was released just few weeks ago and many people around thinking about an upgrade. If you are one of those people, you can be interested in reading Subversion 1.7: Zippy, but should you upgrade? blog post where one of our Polarion colleagues compared performance of SVN 1.6 and 1.7.

Happy Friday to everyone!

Best regards,

Igor Vinnykov

Subversive Team

Re: [subversive-dev] svn not detected in linked resources ?

alexander.gurov@xxxxxxx (Alexander Gurov) — Wed, 23 Nov 2011 09:23:36 GMT

Hi Alex,

22.11.2011 18:44, Alexander Neundorf ÐÐÑÐÑ:

On Tuesday 22 November 2011, Alexander Gurov wrote:

Hi,

So, it's not what I thought about. As I understood your description, the
actual SVN project was checked out by external tool

Yes.

and there is no direct relation between the SVN working copy and any project
in the Eclipse IDE workspace.

Only the linked resources.
But I could put any necessary tags into the .project file or e.g. also a
.subversive file.

Unfortunately it won't help at all.

Subversive (as any other team provider) works by attaching its nature to
the project.

I'm no Eclipse expert. Can you please explain what this means ?
What means attaching ? Can I influence this ? What does "nature" mean here ?

Attaching project to the source control provider nature is an action that could be done like this (line from the Subversive code):

RepositoryProvider.map(project, SVNTeamPlugin.NATURE_ID);

That line means that for the project defined by the variable "project" in an appropriate moments of time will be called code of plug-in that has the same nature as specified by the second parameter (string constant). The "attached nature" setting is the persistent one, so it is stored somewhere inside workspace's ".metadata" folder. You can influence it the same way (just that you'll need to do some calls to the Eclipse Team API), but it won't work in the end because sharing the project is not the same as just attaching source control provider nature to it. It is expected that the shared project should be related to some repository (SVN repository in this exact case) and should contain source control metainformation inside the project root folder. So, I've opened the task related to this discussion on the Subversive tracker (https://bugs.eclipse.org/bugs/show_bug.cgi?id=364547), but I can't even tell you any expectations regarding when it could be done, since it requires great amount of efforts to be applied in both of the Subversive parts: core an UI.

It means, if there are no attachment, then Subversive code
won't be called at all.

As far as I know, the only way to make it work at all is to attach
"build-automoc" project to the SVN (in order to activate source control
plug-in code for the project).

How would I "attach a directoy to SVN" ?

After that next steps will be related to
some corrections in Subversive. As I understand, the "build-automoc"
project in your case shouldn't be shared through the source control, is
it correct or not?


Yes, the build directory is not in source control.
One developer can chose to create Eclipse projects, another one can choose to
generate XCode projects, Windows developers may generate VisualStudio
projects, others will only generate Makefiles.
All this is completely up to the respective developer, and build trees are
"volatile" in that sense.

If so, then the only way to do this is to allow Subversive to be
connected to the project without its actual sharing. This is some

Would it help if I create an actual symbolic link in the file system which
points from build-automoc/ to automoc/ ?

e.g.
$HOME/src/build-automoc/SymlinkToSrcDir
which points to
$HOME/src/automoc/

This would make it work at least for any UNIX, if it would help.

non-trivial solution and for the moment I can't tell how much time it
will take to implement it, as it will cause some serious changes in the
most important parts of the Subversive plug-in code.

If I'm wrong somewhere please correct me. Otherwise, if I understood
your situation correctly, I'll create corresponding task on the tracker.

I think you are right.

Alex
_______________________________________________
subversive-dev mailing list
subversive-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/subversive-dev

Re: [subversive-dev] Version 0.7.9.I20111119-1700 of subversive is not working at all

alexander.gurov@xxxxxxx (Alexander Gurov) — Wed, 23 Nov 2011 07:22:57 GMT

Hello Lars,

The bug you've reported is pretty unique one. It says there is no member field in public Eclipse Platform API, which was introduced in Eclipse Platform 3.4 and is recommended to use instead of older deprecated calls. So, I've moved the issue report to the Eclipse Platform Runtime component and awaiting for an answer or recomendation from the "Eclipse Runtime" Team guys.

Best regards,
Alexander Gurov,
Subversive Team.

23.11.2011 2:58, Lars Sonchocky-Helldorf ÐÐÑÐÑ:

Can somebody please have a look at:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=364464

this bug breaks the whole plug in:

Caused by: java.lang.NoSuchFieldError: INSTANCE
     at org.eclipse.team.svn.core.SVNTeamPlugin.getPreferences(SVNTeamPlugin.java:141)
     at org.eclipse.team.svn.core.svnstorage.AbstractSVNStorage.initialize(AbstractSVNStorage.java:500)
     at org.eclipse.team.svn.core.operation.file.SVNFileStorage.initialize(SVNFileStorage.java:63)
     at org.eclipse.team.svn.core.SVNTeamPlugin.start(SVNTeamPlugin.java:161)
     at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
     at java.security.AccessController.doPrivileged(Native Method)
     at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)


Btw.: This bug got automatically assigned to Igor Burilo. Since I did not see a commit of Igor for quite a long time (about a year) I am asking myself if he is still working on the project.


cheers,

	Lars
_______________________________________________
subversive-dev mailing list
subversive-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/subversive-dev

[subversive-dev] Version 0.7.9.I20111119-1700 of subversive is not working at all

lars.sonchocky-helldorf@xxxxxxx (Lars Sonchocky-Helldorf) — Wed, 23 Nov 2011 00:58:06 GMT

Can somebody please have a look at:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=364464

this bug breaks the whole plug in:

Caused by: java.lang.NoSuchFieldError: INSTANCE
    at org.eclipse.team.svn.core.SVNTeamPlugin.getPreferences(SVNTeamPlugin.java:141)
    at org.eclipse.team.svn.core.svnstorage.AbstractSVNStorage.initialize(AbstractSVNStorage.java:500)
    at org.eclipse.team.svn.core.operation.file.SVNFileStorage.initialize(SVNFileStorage.java:63)
    at org.eclipse.team.svn.core.SVNTeamPlugin.start(SVNTeamPlugin.java:161)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)


Btw.: This bug got automatically assigned to Igor Burilo. Since I did not see a commit of Igor for quite a long time (about a year) I am asking myself if he is still working on the project.


cheers,

	Lars

Re: [subversive-dev] svn not detected in linked resources ?

neundorf@xxxxxxx (Alexander Neundorf) — Tue, 22 Nov 2011 16:46:38 GMT

On Tuesday 22 November 2011, Alexander Gurov wrote:
> Hi,
> 
> So, it's not what I thought about. As I understood your description, the
> actual SVN project was checked out by external tool 

Yes.

> and there is no direct relation between the SVN working copy and any project
> in the Eclipse IDE workspace.

Only the linked resources.
But I could put any necessary tags into the .project file or e.g. also a 
.subversive file.

> Subversive (as any other team provider) works by attaching its nature to
> the project. 

I'm no Eclipse expert. Can you please explain what this means ?
What means attaching ? Can I influence this ? What does "nature" mean here ?

> It means, if there are no attachment, then Subversive code
> won't be called at all.
> 
> As far as I know, the only way to make it work at all is to attach
> "build-automoc" project to the SVN (in order to activate source control
> plug-in code for the project). 

How would I "attach a directoy to SVN" ?

> After that next steps will be related to
> some corrections in Subversive. As I understand, the "build-automoc"
> project in your case shouldn't be shared through the source control, is
> it correct or not?

Yes, the build directory is not in source control.
One developer can chose to create Eclipse projects, another one can choose to 
generate XCode projects, Windows developers may generate VisualStudio 
projects, others will only generate Makefiles.
All this is completely up to the respective developer, and build trees are 
"volatile" in that sense.

> If so, then the only way to do this is to allow Subversive to be
> connected to the project without its actual sharing. This is some

Would it help if I create an actual symbolic link in the file system which 
points from build-automoc/ to automoc/ ?

e.g.
$HOME/src/build-automoc/SymlinkToSrcDir 
which points to 
$HOME/src/automoc/

This would make it work at least for any UNIX, if it would help.

> non-trivial solution and for the moment I can't tell how much time it
> will take to implement it, as it will cause some serious changes in the
> most important parts of the Subversive plug-in code.
> 
> If I'm wrong somewhere please correct me. Otherwise, if I understood
> your situation correctly, I'll create corresponding task on the tracker.

I think you are right.

Alex

[subversive-dev] [ANN] SubGit Early Access Program Build #789

kitaev@xxxxxxx (Alexander Kitaev) — Tue, 22 Nov 2011 16:42:37 GMT

Hello All,

Let me introduce our new project: SubGit (http://subgit.com/).

SubGit is a free tool for smooth migration from Subversion to Git. As
well as from Git to Subversion. Without git-svn insanity.

It works like this:

 - Install SubGit into your repository on the server side
 - Let initial translation complete (time depends on the size of repository)
 - Committers may now use either Git or Subversion (or both) with the
tools of their choice

SubGit EAP builds are free to use builds which you may try and let us
know what do you miss, so that we make sure that all the features you
need are included into the final version of SubGit.

SubGit works on Linux, Windows or OS X and requires Java 5 or newer.
Download new SubGit EAP build from http://subgit.com/

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Two-way ticket to the dark side.
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

Re: [subversive-dev] svn not detected in linked resources ?

alexander.gurov@xxxxxxx (Alexander Gurov) — Tue, 22 Nov 2011 06:39:17 GMT

Hi,

So, it's not what I thought about. As I understood your description, the actual SVN project was checked out by external tool and there is no direct relation between the SVN working copy and any project in the Eclipse IDE workspace.
Subversive (as any other team provider) works by attaching its nature to the project. It means, if there are no attachment, then Subversive code won't be called at all.

As far as I know, the only way to make it work at all is to attach "build-automoc" project to the SVN (in order to activate source control plug-in code for the project). After that next steps will be related to some corrections in Subversive. As I understand, the "build-automoc" project in your case shouldn't be shared through the source control, is it correct or not?

If so, then the only way to do this is to allow Subversive to be connected to the project without its actual sharing. This is some non-trivial solution and for the moment I can't tell how much time it will take to implement it, as it will cause some serious changes in the most important parts of the Subversive plug-in code.

If I'm wrong somewhere please correct me. Otherwise, if I understood your situation correctly, I'll create corresponding task on the tracker.

Best regards,
Alexander.

21.11.2011 22:29, Alexander Neundorf пишет:

Hi Alexander,

On Monday 21 November 2011, Alexander Gurov wrote:

Unfortunately I haven't worked with CDT at all, so there are some points
I can't figure out, it seems. Let's check a few of different project
layouts:

1) If we think in terms of typical Eclipse IDE workspace layout, it will
be something like this:
workspace
workspace/project_1
workspace/project_1/src
workspace/project_1/.project
workpsace/project_2
workspace/project_1/src
workspace/project_2/.project

2) Now if we add SVN into the equation we will get something like this:
workspace
workspace/project_1
workspace/project_1/.svn
workspace/project_1/src
workspace/project_1/src/.svn
workspace/project_1/.project
workpsace/project_2
workspace/project_2/.svn
workspace/project_2/src
workspace/project_2/src/.svn
workspace/project_2/.project

In other words each and every project is the separate SVN working copy
itself.

3) If we use some specific tools like maven, for example, then it could
be like this:
workspace
workspace/.svn
workspace/project_1
workspace/project_1/.svn
workspace/project_1/src
workspace/project_1/src/.svn
workspace/project_1/.project
workpsace/project_2
workspace/project_2/.svn
workspace/project_2/src
workspace/project_2/src/.svn
workspace/project_2/.project

In this case every project is related to the same working copy with its
root placed in the workspace.

So, to sum it up, if I where to add actual processing of the linked
nodes, I need them to be files or folders, that are placed somewhere
inside the actual Eclipse project (project_1 or project_2 in my
examples) or, in the worst case, inside the workspace root in the third
case. Unfortunately I can't clearly see the whole actual structure of
the SVN project in your example.


This is what I check out from svn, just one directory:

$HOME/src/$ svn co http://svn.kde.org/.../automoc

This gives:

$HOME/src/automoc/
$HOME/src/automoc/.svn/
$HOME/src/automoc/CMakeLists.txt
$HOME/src/automoc/main.cpp


My Eclipse workspace is here:
$HOME/src/eclipse-workspace/
but basically I don't do anything with it.


Then I create an out-of-source build-tree, where cmake will generate Makefiles 
and the Eclipse project files for building automoc:

$HOME/src/$ mkdir build-automoc
$HOME/src/$ cd build-automoc
$HOME/src/build-automoc$ cmake-gui ../automoc


This produces the build tree, containing Makefiles and the Eclipse project:

$HOME/src/build-automoc/
$HOME/src/build-automoc/.project
$HOME/src/build-automoc/.cproject
$HOME/src/build-automoc/Makefile
$HOME/src/build-automoc/CMakeCache.txt


In this directory I can run make, and it will build this project.

Then I start Eclipse, and
* do "Import existing project"
* select $HOME/src/build-automoc/ for importing
* keep the checkbox "Copy into workspace" disabled, i.e. the files stay where 
they are, outside my $HOME/src/eclipse-workspace/


Then I have this project in Eclipse, and most things work fine.
Code completion, building targets, etc.

In the generated .project file there is a linked resource pointing to the 
original source checkout directory, i.e. to $HOME/src/automoc/.

This is neither a subdirectory of the directory where the .project file is, 
nor is it inside the Eclipse workspace, as shown above.
The problem is that the "Team" functions do not show up in that directory, 
which is pointed to by the linked resource.

And a build tree for this source tree:

src/automoc-build/
src/automoc-build/.project
src/automoc-build/.cproject
src/automoc-build/Makefile
src/automoc-build/CMakeCache.txt
src/automoc-build/main.o
src/automoc-build/automoc

So, I'll really appreciate it if you
could please provide me with an example of resource tree, starting from
the root of SVN working copy (where the top .svn folder is placed) and
point where the .project file is placed and to where it is linked.
Probably the best way to see it will be a sample project. If that is the
case, then we also have two options:
1) You could send me a sample of a CDT project

The .cproject file probably/maybe does not even matter as far as I understand.
I attached one, the important part is the "[Source directory]" linked 
resource.

2) You could teach me where I should get right CDT version and how to
create and configure the project, so I'll reproduce the situation by
myself.

I'll prepare a sample project and send you later.


Would it work if I would create actual symbolic links in disk to the source 
directory ?
I'll try (...but it would not be ideal, since it wouldn't work under Windows).

Thanks
Alex

_______________________________________________
subversive-dev mailing list
subversive-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/subversive-dev

Re: [subversive-dev] svn not detected in linked resources ?

neundorf@xxxxxxx (Alexander Neundorf) — Mon, 21 Nov 2011 20:31:14 GMT

Hi Alexander,

On Monday 21 November 2011, Alexander Gurov wrote:
> Unfortunately I haven't worked with CDT at all, so there are some points
> I can't figure out, it seems. Let's check a few of different project
> layouts:
> 
> 1) If we think in terms of typical Eclipse IDE workspace layout, it will
> be something like this:
> workspace
> workspace/project_1
> workspace/project_1/src
> workspace/project_1/.project
> workpsace/project_2
> workspace/project_1/src
> workspace/project_2/.project
> 
> 2) Now if we add SVN into the equation we will get something like this:
> workspace
> workspace/project_1
> workspace/project_1/.svn
> workspace/project_1/src
> workspace/project_1/src/.svn
> workspace/project_1/.project
> workpsace/project_2
> workspace/project_2/.svn
> workspace/project_2/src
> workspace/project_2/src/.svn
> workspace/project_2/.project
> 
> In other words each and every project is the separate SVN working copy
> itself.
> 
> 3) If we use some specific tools like maven, for example, then it could
> be like this:
> workspace
> workspace/.svn
> workspace/project_1
> workspace/project_1/.svn
> workspace/project_1/src
> workspace/project_1/src/.svn
> workspace/project_1/.project
> workpsace/project_2
> workspace/project_2/.svn
> workspace/project_2/src
> workspace/project_2/src/.svn
> workspace/project_2/.project
> 
> In this case every project is related to the same working copy with its
> root placed in the workspace.
> 
> So, to sum it up, if I where to add actual processing of the linked
> nodes, I need them to be files or folders, that are placed somewhere
> inside the actual Eclipse project (project_1 or project_2 in my
> examples) or, in the worst case, inside the workspace root in the third
> case. Unfortunately I can't clearly see the whole actual structure of
> the SVN project in your example. 

This is what I check out from svn, just one directory:

$HOME/src/$ svn co http://svn.kde.org/.../automoc

This gives:

$HOME/src/automoc/
$HOME/src/automoc/.svn/
$HOME/src/automoc/CMakeLists.txt
$HOME/src/automoc/main.cpp

My Eclipse workspace is here:
$HOME/src/eclipse-workspace/
but basically I don't do anything with it.

Then I create an out-of-source build-tree, where cmake will generate Makefiles 
and the Eclipse project files for building automoc:

$HOME/src/$ mkdir build-automoc
$HOME/src/$ cd build-automoc
$HOME/src/build-automoc$ cmake-gui ../automoc

This produces the build tree, containing Makefiles and the Eclipse project:

$HOME/src/build-automoc/
$HOME/src/build-automoc/.project
$HOME/src/build-automoc/.cproject
$HOME/src/build-automoc/Makefile
$HOME/src/build-automoc/CMakeCache.txt

In this directory I can run make, and it will build this project.

Then I start Eclipse, and
* do "Import existing project"
* select $HOME/src/build-automoc/ for importing
* keep the checkbox "Copy into workspace" disabled, i.e. the files stay where 
they are, outside my $HOME/src/eclipse-workspace/

Then I have this project in Eclipse, and most things work fine.
Code completion, building targets, etc.

In the generated .project file there is a linked resource pointing to the 
original source checkout directory, i.e. to $HOME/src/automoc/.

This is neither a subdirectory of the directory where the .project file is, 
nor is it inside the Eclipse workspace, as shown above.
The problem is that the "Team" functions do not show up in that directory, 
which is pointed to by the linked resource.

> > And a build tree for this source tree:
> > 
> > src/automoc-build/
> > src/automoc-build/.project
> > src/automoc-build/.cproject
> > src/automoc-build/Makefile
> > src/automoc-build/CMakeCache.txt
> > src/automoc-build/main.o
> > src/automoc-build/automoc

> So, I'll really appreciate it if you
> could please provide me with an example of resource tree, starting from
> the root of SVN working copy (where the top .svn folder is placed) and
> point where the .project file is placed and to where it is linked.
> Probably the best way to see it will be a sample project. If that is the
> case, then we also have two options:
> 1) You could send me a sample of a CDT project

The .cproject file probably/maybe does not even matter as far as I understand.
I attached one, the important part is the "[Source directory]" linked 
resource.

> 2) You could teach me where I should get right CDT version and how to
> create and configure the project, so I'll reproduce the situation by
> myself.

I'll prepare a sample project and send you later.

Would it work if I would create actual symbolic links in disk to the source 
directory ?
I'll try (...but it would not be ideal, since it wouldn't work under Windows).

Thanks
Alex

Attachment: .project
Description: application/xml