• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

A set of questions remained after reading SVN book.

 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings, Gentlemen!

I just have finished reading of SVN book, and want to clear up several questions.

1) What can I do if I need to switch to HEAD revision for some time and correct some bug immediately? Looks like in SVN the only way is to have a separate checkout of repo for this kind of tasks. In Git, for example, you can create several local branches, or stash your changes.

2) Which svn commands except for standart checkout/merge/update/delete/add make your life with SVN happier?

3) Is it possible to set permissions for some repository folders? For example, make each developer having access only to his project folder.

4) Some times after calling svn status I saw a reply:

svn status
M FolderName


What does it mean? Folder name is unmodified, and no changes inside the folder took place. Why folder is considered modified?

5) Looks like i cannot cancel merge if a conflict was discovered, can I?
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1) SVN is like most version control systems in that in order to work on a variant of a project, you have to check out a local working copy of the project, work with that and then (assuming you want the changes under source control) check the updated variant in. The easiest way of doing this when you don't want to post the changes to the HEAD of that branch is to construct a new branch using the svn "copy" command and then check out the new branch. Actually, by definition, the latest set of updates to a branch are the HEAD - you cannot update a revision unless you are George Orwell.

Note that in SVN a copy operation is low-penalty. SVN keeps virtualized copies of the files, so only changed files are actually distinct (eating disk space) within the archive itself.

2) I don't really pay attention, since a lot of my SVN operations are done via the IDE plugin, but there's a "fixup" command that I wish I never had to use but am grateful to have when I have to use it anyway.

3) SVN has 2 primary security systems. When using the SVN server, security is configured using a set of files in the SVN archive itself. When using a web server, the web server access control system is used. Common practice seems to be to not be very fine-grained on access control, however. In my case, I have completely separate archives for my public stuff (open-source projects and code samples) and my private (client-specific) stuff. The private stuff is access-controlled via Apache security.

4) I cannot say what's setting your folder modification flag, although anything that changes your folder characteristics is likely to trigger it.

5) One of the major selling points of CVN is that commits are atomic. You should be able to about a commit, but not cancel it in the sense that only certain changes get committed. In the case of a merge, normally you would create a merge copy of the project, reconcile all of the conflicts within that copy, then commit the reconciled copy. Or just abandon the whole thing if it's too much trouble. Since SVN doesn't lock project checkouts, it won't care if you just send the whole thing to the trash can.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic