0

There is a project that uses CVSNT/WinCVS for Version Control. This is the central repository. Locally checked out folders contain hidden sub-folder called "CVS".

I tried to install CVSNT server locally and use second instance of WinCVS to manage(version control) local temporary changes before committing to the central repository.

But that is not working because when checking out from the second(local) repository it still uses "CVS" sub-folder name for its working files.

Anybody knows if it is possible to configure CVSNT server and/or Client to use different name for this sub-folder? And if yes, how?

So far I'm using TortoiseSVN. It creates folders too, but they called ".svn" so there is no interference. It is integrated in Windows shell, which I don't like.

sny
  • 415
  • 8
  • 21
  • The first one uses remote repository and is used by several people. There are no synchronization issues as I am using the second one (local) for temporary development before changes are ready to go to the main one. – sny Feb 23 '12 at 01:07

1 Answers1

1

A sandbox is tied to a given repository (which is regitered in one of the files in the hidden CVS folders). You can't use the same sandbox to commit locally and remote (are you tring to mimic a DVCS? Use one of them if you need them). You can't change the folder name (but changing the CVS source files...), but beware WInCVS use them as well because they contains informations about the files status.

You have two options:

  • The CVS way: create your own development branch, commit to that, merge with the main branch when your code is ready. Of course the CVS server has to be reachable all the time.
  • The DIY way: create two sandbox, one from the local repository, one from the remote one, move files between them as you need. This is a more error prone way, IMHO.

Of course you can try to use two different VCS, but you will end up with a lot of headaches then. Better to use Git, Mercurial or the like that do what you need without any special configuration.

Mad Hatter
  • 772
  • 5
  • 5
  • No I'm not trying to use DVCS here. – sny Jul 06 '12 at 06:24
  • The first option is not good due to company policy (keeping it clean from many temporary changes of each developer). The second one ... I better use the Windows shell integrated Tortoise. – sny Jul 06 '12 at 06:30
  • To use Git or Mercurial I have to clarify that **I don't want my temporary commit history to go to the central repository**. Only the "locally" final code. **Can Git or Mercurial do that? i.e. create local branch and not send it to the repository.** – sny Jul 06 '12 at 06:34
  • Yes. DVCS allows you to work locally and then "push/pull" the changes you want to the central repository. Anyway, you're company policies are wrong. When a bug/issue enters code, I *want* to know when it was introduced, and usually as soon as possible, not days/weeks/months later. Unless, of course, you run build automated tests locally as well... – Mad Hatter Jul 10 '12 at 10:02
  • Thanks for replies. I appreciate it. But there seems to be misunderstanding on company policy and my intentions area. – sny Jul 11 '12 at 23:28
  • Thanks for replies. I appreciate it. But there seems to be misunderstanding on company policy and my intentions area. Bug fix or new feature go to central repo as soon as ready. Before that, my local development might take some experiments, take some time, take some stop-switch_to_other_task-switch_back so leave redundant comments/reminders etc - that is what I try to track locally. After commit to central repo the local tree doesn't make sense, and is considered starting from that point. – sny Jul 11 '12 at 23:36
  • To use DVCS the way you proposed, the company has to install it. I might try to use it instead SVN (Tortoise in my case) just for the sake of learning it. – sny Jul 11 '12 at 23:40
  • 1
    If your company policy is to get only commits of finished code it should really think about installing a DVCS. Anyway, beware that unless you backup your PC often enough, you're still risking to lose valuable work as long as it is on your machine only. That's one reason I believe it is often better to push even unfinished changes to a branch on a remote, reduntant, backed up machine. – Mad Hatter Jul 16 '12 at 12:29