Source code revision control

Go To Last Post
73 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

you end up with two changesets for the one commit

OK, that actually answers my question! Git knows about what was merged and what was conflict resolution.

For subversion a changed WC is a changed WC. At commit the SVN CI command does not in any way know who/what did what changes to the WC.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Neat!

Until you want to find *.cpp and *.h !

In that case -regex is possible but, to be honest, I'd just stick with -or:

find . -name *.cpp -or -name *.h

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
UnDromader wrote:
SVN for single user...
GIT for multiple users...
Maybe it is a language thing, but SVN is for multiple users. Keeping multiple users from stepping on each other files is a main reason for all version control systems. Am I missing something?

Smiley


No Smiley you don't miss anything, but I have made a pro/cons score for both source control engines and exposed my conclusions.
You can use SVN with a team of over 50 people, but a good discipline is required (enforced by an automated testing system, is not enough to resolve merging conflicts, the most expensive conflicts are at logical level).
Also you can use GIT as single user, but the gain over SVN is minimal(the distributed part is not adding any gain) and the loss is somehow great (the tips about keeping in the same directory more subdirectories linked to different paths to the repository - or even other versions of the same paths - mainly to "access" code shared between projects).
Dean in about 7 years of SVN use I didn't had problems with the repository (few different SVN server setups along the way). My projects are not trivial (over 60000 lines of code). As for the occupied space I don't really think that today is an issue to get 2 HDD of 1.5 TB and put them in mirror. To give you a better picture of git/svn confidence: I am using git for over 2 years now, and just for git made a git panic command (in my powershell profile) that will make an dated archive from my current folder.

Last Edited: Fri. Mar 9, 2012 - 11:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess I am like a lot of people here, I am using TortoiseSVN in Windows with a local repositery, very easy to use, and to backup.

I tried TortoiseCVS but couldn't find a free version or how to use a local folder for repositery, after trying a few hours I trashed it to use SVN instead.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:

A tag should be nothing more than literal revision tag, like Git does it - why make a copy when it is just a revision reference?

Although the command you use for tagging is "svn copy", it's actually implemented as a revision reference. Look:

$ svn log -v -r1242838 http://svn.apache.org/repos/asf/subversion/tags/1.7.3 
------------------------------------------------------------------------
r1242838 | hwright | 2012-02-11 03:16:17 +1100 (Sat, 11 Feb 2012) | 1 line
Changed paths:
   A /subversion/tags/1.7.3 (from /subversion/branches/1.7.x:1242825)
   M /subversion/tags/1.7.3/subversion/include/svn_version.h

Tagging release 1.7.3 with svn_version.h matching tarball.
------------------------------------------------------------------------

It's only when you view or checkout that pathname do you see the expansion into the file tree at the target of that reference. In that sense, a "svn copy" is more like a symlink.

$ svn ls -r1242838 http://svn.apache.org/repos/asf/subversion/tags/1.7.3 
BUGS
CHANGES
COMMITTERS
INSTALL
LICENSE
Makefile.in


- S

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Neat!

Until you want to find *.cpp and *.h !

In that case -regex is possible but, to be honest, I'd just stick with -or:

find . -name *.cpp -or -name *.h

Don't you mean
find . -name \*.cpp -or -name \*.h

How about

find . -name '\*.{cpp,h}'

What is WC?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Everyone,

Ok, I suppose I'm in the "dark ages" of source code version-ing. I've never used a tool like this, and for a single developer situation like I am in, if I'm going from 1.00 to 1.01, I may copy the file myprog.c to myproc.100 before modifying it. Then again, I may not.

Is the added complexity of a SVN and backing it up, keeping track of its database, etc., worthwhile? Perhaps I just don't know what I am missing...

Thanks,

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
What is WC?

Working Copy. (Subversion terminology.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:

Is the added complexity of a SVN and backing it up, keeping track of its database, etc., worthwhile? Perhaps I just don't know what I am missing...

Without doubt.

What might change your mind is how is integrates with trac (free) and fisheye ($10) in order to see the differences between versions and branches.

Other SCM systems are similar.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:
Is the added complexity of a SVN and backing it up, keeping track of its database, etc., worthwhile? Perhaps I just don't know what I am missing...
As a 3-day old user of TortoiseSVN with a file-based repository on Windows 7...I don't really know how I managed without it. Every time I get a new feature working in the code (which may take a few iterations of the WC files) then a single RMB click on "SVN Commit..." for the WC folder and I know I have a safe copy (version-controlled safe, rather than back-up safe) that I can always go back to (with one click) and start out again

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Been following this thread with interest, and just installed TortoiseSVN under Win 7 64.
Since I have been using(fighting?) Studio 5 for a while now, I have to ask if there are any gotchas associated with Studio 5's weird(to me, at any rate) habit of placing files in sub folders according to some unknown(again, to me) rule. Or indeed the optional practice of linking to files, rather than copying them, when adding sources.
I am concerned that retrofitting TortoiseSVN to my existing projects might cause me some grief, any reassurance welcome!

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Or indeed the optional practice of linking to files, rather than copying them, when adding sources.
I am concerned that retrofitting TortoiseSVN to my existing projects

Well, storing the links in a subversion repository makes little sense. Either copy the files, rather than accepting the default link behavior, when adding a file to Atmel Studio. Or go the whole way and build files that are shared between projects into a project of their own that produces a library rather than an executable - all source files are proper in projects, no links anywhere. (Now you have to ponder how to organize your repository, but that is another thing.)

Aside: I really, really, really wonder what went on in the head of the Atmel person that decided that link would be default. I guess they realized that when people add ASF stuff to their projects they will be close to impossible to have up to date when a new ASF version comes out. They should have made ASF a proper library, I suppose.. (But then again, I'm not an ASF user at all so I might be totally off..) Or that person made the descision after having been treated to all that free booze by the Microsoft guys. :evil:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Without doubt.

+1
Quote:

with trac (free)

We use that corporately (and CDash and Cmake). All great tools.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I started with git. Since I'm just working by myself, it's pretty straightforward. I just run 'git init' in my project directory and then 'git add .' to add everything. At this point I just do a commit whenever I think it makes sense to 'save my progress'. I will have to learn about branching when it comes to that.

Should I create a git repo for each "project" or should I just create one master git repo for all my programs, even ones which aren't related?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Should I create a git repo for each "project" or should I just create one master git repo for all my programs, even ones which aren't related?

Remember the point about backing up repos - do you want lots of small ones or one big one? There are +'s and -'s to both approaches.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One advantage of DRCS versus RCS is the repository is copied (it's a backup). If a/the repository is on a NAS that's another backup and another backup via the NAS's easy backup function (onto SD card or USB stick). If open and free(dom) software, free(beer) backup is available on the net.
I have a bit of hard luck with hard drives.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm.. I have only started to dip my toe in the water here, but the help docs say that the file icons in my working copy folder should have overlays to flag their status - they don't. Am I doing something stupid(apart form trying to teach an old dog...)?

Quote:
You will notice that the appearance of this folder is different from our original folder. Every file has a green check mark in the bottom left corner. These are TortoiseSVN's status icons which are only present in a working copy. The green state indicates that the file is unchanged from the version in the repository.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Hmm.. I have only started to dip my toe in the water here, but the help docs say that the file icons in my working copy folder should have overlays to flag their status - they don't. Am I doing something stupid(apart form trying to teach an old dog...)?

This could be either:

1) You've installed the 32-bit version of Tortoise on a x64 bit machine (or vice-versa)
2) You haven't restarted since installing Tortoise
3) Your repository is gigantic and Tortoise's caching mechanism hasn't caught up yet

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The occasion on which I didn't see the icons when I was expecting (which actually lead me to copy a 1GB source tree from one drive to another) was because I later found this - by default "Network drives" is not ticked!

(I kicked myself later when I realised it was a simple as a single tick).

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Quote:

Hmm.. I have only started to dip my toe in the water here, but the help docs say that the file icons in my working copy folder should have overlays to flag their status - they don't. Am I doing something stupid(apart form trying to teach an old dog...)?

This could be either:

1) You've installed the 32-bit version of Tortoise on a x64 bit machine (or vice-versa)
2) You haven't restarted since installing Tortoise
3) Your repository is gigantic and Tortoise's caching mechanism hasn't caught up yet

- Dean :twisted:

Thanks, Dean. It was 2).

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem I now have is that, after importing an existing project to my repos, and then checking out a working copy to a new directory, I seem to have duplicated files, this is possibly related to my shaky understanding of what Studio 5 refers to as "solutions" and "projects". I've always accepted wherever Studio 5 wants to create new files for my app, because I haven't worked out either:
a) Why it does what it does.
or
b) How to alter its behaviour.

So I always seem to end up with files split over two directory levels. TortoiseSVN seems to have duplicated most of my files in both levels. Studio 5 still works, and builds the app, but I'd like to resolve this sometime.

[Edit] Later that same day: Weirdly, it seems that if I delete all the source files(.C .H and .S) from the "solution" level, but leave them in the "project" folder, Studio 5 finds them all and builds OK. [/Edit].

Four legs good, two legs bad, three legs stable.

Pages