블로그 이미지
Every unexpected event is a path to learning for you.

카테고리

분류 전체보기 (2307)
Unity3D (564)
Programming (470)
Unreal (4)
Gamebryo (56)
Tip & Tech (182)
협업 (34)
3DS Max (3)
Game (12)
Utility (114)
Etc (92)
Link (31)
Portfolio (19)
Subject (90)
iOS,OSX (37)
Android (12)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (1)
Memories (19)
Interest (37)
Thinking (36)
한글 (26)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (19)
Exercise (3)
나만의 맛집 (2)
냥이 (9)
육아 (5)
Total1,331,909
Today12
Yesterday172
Statistics Graph

달력

« » 2019.10
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

공지사항

태그목록

'tag'에 해당되는 글 2건

  1. 2018.02.21 [펌] Git: Zombie tags from hell
  2. 2012.04.18 TortoiseSVN - branch, tag, merge, switch

I love Git. I was very much a TFS purist up until the last year or so, but after using Git for a while now, I’m hooked. Whilst TFS certainly isn’t bad, I love the flexibility and the fact I can muck about to my hearts content in a DVCS without affecting anyone (unless I choose to). That doesn’t mean I love everything though, one of my biggest headaches recently has been tags.

Tags in Git are simply textual markers against specific commits, very much like branches (although tags don’t move). Generally they’re used to mark points in your commit history (i.e. versions etc), but they can – being just text – be used to mark anything really.

So what’s the problem? Well, the issue isn’t with tags themselves, it’s more with the fact they’re very, very annoying to kill. I purposefully say kill and not delete, because deleting a tag is actually very simple, it’s making sure that tag staysdeleted/dead that’s the problem. Once a tag has been pushed to a remote, it is automatically retrieved during any subsequent pulls, at this point the tag exists in the user’s local repository until they choose to delete it. But it also means that said user can also then re-push a single tag – or even worse, all their local tags – to a remote when doing a push.

To illustrate this, consider the following example:

  1. Bob creates the tag ‘foo’ against a commit and pushes this to a remote
  2. Fred pulls from the remote to update his local copy of a branch he’s working on with Jane
  3. Jane does the same as Fred, meaning both Fred and Jane now have Bob’s tag ‘foo’ in their local repos
  4. Bob realises that ‘foo’ is a terrible name for a tag and wants to delete it, so he deletes the tag locally and pushes the delete to the remote
  5. Fred has written some more code he wants to share with Jane, so – using his handy Atlassian SourceTree app – he pushes his changes. But; Fred doesn’t 100% understand what he’s doing, so he checks the “Push all tags” checkbox when doing his push, thus re-pushing the tag which Bob just deleted!
  6. Bob does a further pull later that day, and lo and behold, his poorly named tag ‘foo’ has reappeared in his local repository!
  7. Jane pulls again and also pulls down the once deleted tag, much to Bob’s annoyance

Alright, so the answer here is probably to give Fred some guidance about how to use Git, but it does illustrate the real life problem I had recently, the only difference was that in my situation there were lots more developers involved.

So how do you solve this? Well, the Git documentation states that – by default – tags are not pushed unless you specify otherwise (using the “tags” switch). So actually, Git does a pretty good job of preventing people from automatically sharing all their tags, but tools like SourceTree, which provide a seductive “Push all tags” checkbox when pushing – are clearly too tempting for developers to pass up:

SourceTreePushDialog   

Another option – and probably a better one than just relying on your developers to not push their tags – is to implement a pre-receive server side hook to check whether tags are being pushed and reject the push it the user doesn’t have permission. Unfortunately, if you’re using a hosted Git repository like GitHub or Bitbucket, you’re out of luck as they don’t currently provide the ability for you to edit hooks and unfortunately don’t allow you to apply permissions to tags. This is a real shame as the functionality is already there to control access to branches.

Of course, the final option is just to accept that tags are not really meant to be deleted after they’re pushed, which is all well and good if you and your developers understand this from the start, not so good if not!


[출처] http://thecurlybracket.com/2014/10/11/git-zombie-tags-from-hell/

Posted by blueasa
TAG Git, tag, Zombie

댓글을 달아 주세요

TortoiseSVN으로 brench/tag를 관리해 보자.

 

작업하기 전에 SVN서버에 디렉토리를 만들때 repository/project01/trunk 형태로 만들고 trunk 아래에 project의 모든 파일을 둔다. 그렇게 하고 모든 작업은 trunk에서 한다.

 

 

<< brench >>

 

brench를 만들 필요가 생기면(코드에 큰 변화가 있거나, 기능을 테스트 하거나, 수정기간이 오래걸릴때 등등..)

 

먼저 trunk폴더를 commit이나 update해서 최신상태로 만든다.

탐색기의 trunk 폴더에 마우스 오른쪽 클릭해서 Brench/tag 를 클릭한다.

Copy(Brench/tag) 창이 뜬다.

To URL에 복사본을 만들 폴더경로를 입력한다. 필요하면 ... 버튼 눌러서 SVN서버에 직접 필요한 폴더를 만든다.

project01/brenches/funcA 라고 입력하려면 brenches 폴더까지는 존재해하고 funcA폴더는 없어야 한다.

project01/brenches/funcA <-- 이 경로의 의미는 funcA란 기능을 테스트하기위한 brench를 만들겠다는 의미다.

brench는 한꺼번에 여러개 만들어놓고 사용할 경우가 있기때문에 brenches폴더를 따로 만들어 한꺼번에 관리하는게 폴더구조가 깔끔할듯 함.

 

이렇게 해놓고 필요하면 Log message를 입력하고나서,

맨 아래쪽에 있는 Switch working copy to new brench.tag 를 체크하고 OK를 누르면 SVN서버에 brech가 한개 만들어지게 된다.

 

이상태는 trunk폴더는 repository/project01/brench/funcA사본에 연결된 상태이다.

반드시 trunk폴더를 repository/project01/trunk 사본에 연결시켜야 된다.

이거 안하면 낭패본다.


Switch working copy to new brench.tag 이거를 체크 안하면 trunk폴더를 따로 Switch해줄 필요는 없는것 같다.

(이게 좋겠다..)


 

여기까지하면 서버의 repository/project01/ 에는 trunk, brench/funcA 폴더가 있고, 두 폴더에는 똑같은 파일들이 있다.

이 상태에서 탐색기의 project01 폴더에서 update해보면 서버의 폴더구조가 그대로 내려온다.

trunk에서의 작업은 trunk 폴더에서 trunk로 switch해서 작업하고,

brench/funcA 에서의 작업은 brench/funcA 폴더에서 brench/funcA로 switch해서 작업하면 됨.

 

 

*** 조심할 내용 ***

탐색기의 trunk 폴더에서 작업하더라고 switch 를 brench/funcA로 해두면 brench/funcA 의 내용이 다운받아진다.

이상태로 작업하고 commit하면 당연히 서버의 brench/funcA내용이 갱신된다. update도 마찬가지인다.

이거 햇갈리면 큰일난다. <-- 반나절 삽질후 깨달음... OTL

즉 swich라는것은 project01안의 여러사본중에 어떤 사본을 다운받아서 작업할지 선택하는 것임.

 

 

<< merge >>

 

brench/funcA 에서 작업이 끝나면 trunk로 merge한다.

trunk폴더에서 trunk로 switch해 놓은 상태로 마우스 오른쪽 클릭해서 merge 선택한다.

세가지 merge 타입을 선택하라고 하면 제일 위의 것(Merge a range of revision) 선택 하고 next

URL to merge from : brench/funcA의 경로를 선택

Revision range to merge : brench/funcA의 리비전중에서 merge할 범위(선택 안하면 모든 리비전을 다 merge함)

Working Copy : trunk의 경로

위와같이 입력하고 next -> Test merge해보면 어떻게 merge될지 미리한번 볼 수 있음.

merge 버튼을 누르면 brench/funcA의 변경,추가사항이 trunk로 합쳐진다.

같은 파일을 같이 수정한것들이 있으면 conflict 될것이고, 이 경우는 코드를 보면서 하나씩 수정해 줘야한다. (이런것까지 자동으로 할수는 없음...)

trunk에 적용되어있는 변경내용은 commit해줘야 서버의 trunk 폴더에 적용이 된다.

 

 

<< tag >>

 

tag는 merge와 똑같다.

tags라는 폴더를 만들어 놓고 여러개의 tag를 관리하길 추천함.

tags/release_version1.0,  tags/release_version2.0  같은 식으로..

이렇게 만들어진 tags는 건드리면 안됨.

현재 상태를 완벽하게 보관하기 위해서 사용함.



[출처] TortoiseSVN - branch, tag, merge, switch|작성자 베이스캠프

'Tip & Tech > TortoiseSVN' 카테고리의 다른 글

excel, word, ppt 가 동일한지 판별하기  (0) 2013.04.26
TortoiseSVN tag/branch = copy  (0) 2012.04.18
TortoiseSVN - branch, tag, merge, switch  (0) 2012.04.18
TortoiseSVN Beginner Guide  (0) 2012.04.18
Posted by blueasa

댓글을 달아 주세요