Tortoisesvn //TOP\\ Download Project
Shara Mchale
Indexing by project makes sense if the projects are not closely related and each one is checked out individually. For related projects where you may want to check out all projects in one go, or where the projects are all tied together in a single distribution package, it is often better to index by branch. This way you have only one trunk to checkout, and the relationships between the sub-projects is more easily visible.
For unrelated projects you may prefer to use separate repositories. When you commit changes, it is the revision number of the whole repository which changes, not the revision number of the project. Having 2 unrelated projects share a repository can mean large gaps in the revision numbers. The Subversion and TortoiseSVN projects appear at the same host address, but are completely separate repositories allowing independent development, and no confusion over build numbers.
The project monitor scans each project in a configurable interval, and every time new commits are detected a notification popup is shown. Also the icon that is added to the system tray changes to indicate that there are new commits.
The fields Username and Password should only be filled in if the repository does not provide anonymous read access, and only if the authentication is not stored by Subversion itself. If you're accessing the monitored repository with TortoiseSVN or other svn clients and you've stored the authentication already, you should leave this empty: you won't have to edit those projects manually if the password changes.
If there are a lot of users monitoring the same repository and the bandwidth on the server is limited, a repository admin can set the minimum for check intervals using an svnrobots.txt file. A detailed explanation on how this works can be found on the project monitor website:
My question is regarding moving and renaming files. In this project I sometimes end up changing my mind about how I want a function to be used, and end up renaming it. Usually something simple; for example, "Edit test settings" to "Edit global test settings" or something. Sometimes it ends up being a folder that gets moved and a dozen VI's get affected (their path changes but their name doesn't).
When I commit this change to SVN, it detects the new file as being added and the old one as missing. I don't see a way to tell it that I renamed something apart from manually doing that to each file within the repo browser, but that means the LabVIEW project goes nuts the next time you try to open it and it can't find the old file. I've had bad experiences trying to batch-rename files like that, so I always do it within the Project environment.
It's simple to just mark the old files as "deleted" in SVN, then add the new ones. This works for a few small unimportant VI's here and there, but I'm wondering if there's a better way. Note that I don't have SVN integrated into my project- is there some integration mechanism that would automatically notify SVN that I renamed a file from within the project? If so how might I set that up?
Sorry for not reading your post carefully. I manage the source-tree without a LabVIEW project, but use a project (later) for creating EXEs and Installers. I just live with the occasional pain of relinking after SVN rename. It may not be a "best practice" (as defined by consensus) but it works for me!
Outside Eclipse, import the project folder into the repository previously created with TortoiseSVN (Right click on folder > TortoiseSVN > Import and select the URL of the repository). Once imported, you may wish to delete the project folder.
On 21.02.2017 17:16, Stefan Hett wrote:
> Hi,
>
> it happened regularly in the past for me that all the projects I added
> to the project monitor suddenly vanished. I think it corresponded to the
> cases where I installed the nightly build of TSVN 1.9. Is there a known
> limitation in this regards and/or does that ring a bell directly on what
> might cause this behavior?
>
> Note that I'm using the project monitor successfully for a couple of
> months on a different machine where I don't use nightly builds. There, I
> never ran into this problem of projects being reset.
>
> @StefanK in case you are picking this up: Please don't spend much time
> on it. It might very well be a local issue and I would not feel good if
> that post would cause you wasting time on a none-issue. I'll get back on
> this one if it becomes more annoying and I actually invest some time in
> debugging the problem myself...
The project monitor settings are saved to
%appdata%\TortoiseSVN\MonitoringData.ini.
They're saved on exit and loaded on start, with a retry count of 5 and a
wait time between tries of half a second.
There's even a backup file MonitoringData_backup.ini in case the
original file can't be loaded.
Not sure how it can happen that both files get corrupted on your machine.
But you can export all the settings (including the project monitor data)
from the settings dialog->Sync->Export settings to file...
If you do that, then you can restore all data easily again with the
"Import Settings from file..." button in the same dialog.
Also, you can set up a sync location, e.g. in your onedrive folder which
then makes all settings sync across machines - and as a bonus it also
creates a backup of your settings.
Stefan
-- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/> The coolest interface to (Sub)version control /_/ \_\ ------------------------------------------------------ =4061&dsMessageId=3212399To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].Received on 2017-02-21 19:58:46 CET
- This message: [ Message body ]
- Next message: Tobias Knauss: "Bug: SubWCRev flags faulty"
- Previous message: Stefan Hett: "Re: Unable to run Cleanup due to a missing file"
- In reply to: Stefan Hett: "Project Monitor losing recorded projects"
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
PS. As a side note - as there seem to be more and more people using source control with LabVIEW, and with it comes a whole bunch of issues, is it worth a separate forum for source code control / project management type things in LAVA?
Welcome to subversion.apache.org, the online home of the Apache Subversion software project. Subversion is an open source version control system. Founded in 2000 by CollabNet, Inc., the Subversion project and software have seen incredible success over the past decade. Subversion has enjoyed and continues to enjoy widespread adoption in both the open source arena and the corporate world.
Subversion is developed as a project of the Apache Software Foundation, and as such is part of a rich community of developers and users. We're always in need of individuals with a wide range of skills, and we invite you to participate in the development of Apache Subversion. Here's how to get started.
Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations.
A linkage involves specifying where you want to connect shared code into your local tree. You can make that specification right at the connection point itself but you are not limited to that point-you can actually specify the connection elsewhere (e.g. at the root of your project)!
Inevitably, when you have several projects under source control you will want to avoid duplication of code by sharing some code between two or more of them. Subversion provides a facility for linking projects in order to make this possible. In Figure 4-1, for example, you have two projects sharing some common code. This is quite simple in concept, but since they are separate projects in your Subversion repository, how then can they both include the common library under source control?
The answer is to promote the Common Library so it is also a first-class project in Subversion: Then have both projects (Projects A and B) each establish a link at the appropriate point in their respective project trees (Figure 4-2).
The first key field is the connection point (the Local path field in Figure 4-3). What you specify for the connection point depends on where you define the svn:externals property. This is not some global setting but, like all Subversion properties, must be attached to one or more files or folders in your tree. This specific property, though, should be attached to just a single folder. There are two obvious choices for which folder to attach to: the project root folder or the linkage point itself. Suppose that the connection folder in Figure 4-2 for Project A is named libs. Underneath libs you want to have the CommonLibrary folder but with a different name, say common. If you choose to define svn:externals on the root folder of Project A, set Local path to libs/common (i.e. the path from the root to the linkage point) and include, as the leaf node of the path, the name of the folder that the linked folder will assume. If you choose instead to define svn:externals on the libs folder then just give Local path the value common. In other words, Local path is simply a relative file path from the folder on which you define the property to the connection point.
Thus far, the examples have shown how to share code from projects within the same repository. But that is not an inherent limitation of Subversion; you can easily refer to projects in different repositories and you can still use relative URLs! You might, for example, have a single parent folder containing a collection of repositories on your server, making all the repositories siblings. You can then just combine the current-directory-relative accessor with the repository-relative accessor to reference a sibling repository, as in ^/../OtherRepo/trunk/CommonLibrary.
df19127ead